[wp-hackers] PostgreSQL port status?

[Computer Guru]

I don't understand why you have to do all that in the first place - shouldn't overloading/replacing wp-db with a wp-db2 do the trick?

In the code you have stuff like

(taken from the code at random)

$arc_result = $wpdb->get_results( $arc_query );


So the changes you'd need:

Check if wp-db2.php exists.
If it does, load $wp-db2 instead of $wp-db.

wp-db2.php can contain all the MySQL to PGSQL voodoo...

At that point, if you have rewritten the base WP queries to support multiple databases you should be good to go. If you haven't - that's what the MySQL to PGSQL rewriter functions are for. No need to actually *manually* modify any queries assuming they're originally written correctly and that your regex/str functions do their conversion properly.

It'd require minimal modification of WP-core and wouldn't add any load at all for non-PGSQL users (and for PGSQL users it'd only add 50 or so regex calls, not that big of a deal).


Computer Guru
NeoSmart Technologies
http://neosmart.net/


> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-
> bounces at lists.automattic.com] On Behalf Of Jacob
> Sent: Monday, October 01, 2007 4:59 AM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] PostgreSQL port status?
> 
> Yes, yes it would most likely slow WordPress down a lot.
> 
> I was thinking more of a custom filter solution. For example:
> 
> instead of add_filter('sql_fetch_category_xyz', 'SELECT * FROM
> whatever');
> 
> more like:
> 
> wp_sql_filter($tag, $sql)
> {
> global $database_type;
> 
> $results = '';
> 
> $function = $tag.'_'.$database_type;
> 
> if( function_exists($function) )
> {
>     $results = $function($sql); // Err, would this work? Might just
> have
> to use call_user_func() instead.
>     return $results;
> }
> 
> return false;
> }
> 
> In this way, you would only need to check to see whether the function
> existed. This would "solved" (crossed your fingers) the incompatibility
> of $wpdb, as it would be bypassed completely. The pseudo-code would be
> quick as hell as it would remove the overhead of _wp_filter_unique_id()
> and the rest of the Filter/Action API.
> 
> It could be used in the code, like so:
> 
> // ... snip
> 
> $sql = 'SELECT * FROM wp_tags';
> $results = wp_sql_filter('wp_get_tags', $sql);
> 
> if($results  !== false)
> {
>     $results = $wpdb->fetch_query($sql);
> }
> 
> return $results;
> 
> 
> Matt wrote:
> > On 9/30/07, Jacob <wordpress at santosj.name> wrote:
> >
> >> My thoughts was having all of the queries as filters specific to the
> >> function and query. You would end up with about several hundred
> filters,
> >> but it would allow for the easiest transition. It wouldn't be as
> hard or
> >> difficult as porting and can be just a plugin. It would also allow
> for
> >> removing upgrading conflicts.
> >>
> >>
> > Wouldn't that slow WordPress down, like a lot?
> >
> >
> >
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers