[wp-hackers] PostgreSQL port status?

[Jacob]

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?
>
>
>