[wp-hackers] PostgreSQL port status?

[Jacob]

Well, like DD32 said, yes, it would most likely do that. However, the 
SQL rewriter seems extremely difficult. Good luck with that. If you were 
going to do that, then I think the PEAR MDB2 package would be a far 
better solution. The SOC student wrote code that does just this, so you 
could either rip the code that the guy had and build the new SQL from 
that persons tree, which might be better.

I think that even if it would be more work, it would be far easier than 
your method describe by both DD32 and you. Actually, I think both would 
require tremendous amount of work, just one would require more work to 
the core, while the other would require SQL find and replace.

Does my idea seem okay then? I'm thinking that DD32 had it right. The 
easiest way would be to use filters and replace the class in $wpdb with 
your own. However, the overhead with as many filters that would be 
required and I think with some SQL engines (SQLite perhaps), it might 
require more than one query.

Thinking about that possibility, I thought it might just be better to 
use a single function that calls another function if it exists. The 
solution would also be better since it would allow, like the above 
paragraph, a single drop in plugin solution, instead of having to port 
the functions and hack the core.

I'm willing to do some work on this if anyone (about two) think it is 
worth the time and willing to do profiling to see if it adds any 
unneeded overhead costs.

Jacob Santos

Computer Guru wrote:
> 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
>>     
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>