[wp-hackers] PostgreSQL port status?

[Jacob]

Perhaps, you are right. However, we wouldn't know, unless the the core 
devs join this discussion, which seems unlikely since it would appear 
like the dozen others before it.

In my opinion, I would have liked to have used SQLite and had an easy 
way to do it. However, the thought of having to do find and replace 
lowers my motivation to even attempt it.

Which ever method might work, I however won't even attempt it if it is 
required that I do the find and replace method. I would with my method. 
The devs wouldn't have to support any other DB other than MySQL, so 
they'll be allowed to use any MySQL SQL and table scheme they want. This 
solution would allow for those who want to support other Databases to do 
so without forking and give an easy but time consuming way to do so.

Both methods would require a lot of work for the plugin or fork author. 
Mine would require some up front core changes, which would be a lot of 
work in itself. I think the only issue I would have, is if the core team 
would accept such a patch that would do so many changes? I think with 
the prepare stuff, right now isn't the best time, unless there already 
existed a patch. Any patch at this moment would be worthless since it 
wouldn't be able to be applied without conflicts.

This isn't an issue that I'm concerned with, so I'll bow out from voting 
on the issue. I'm just offering a possible solution.

Jacob Santos

Jared Bangs wrote:
> On 9/30/07, Matt <speedboxer at gmail.com> wrote:
>   
>> There's nothing wrong with WP supporting multiple DBs, but doing so in a way
>> that doesn't interfere with anything is the problem...
>>
>>     
>
> Yeah, I would think that if a drop in replacement for the wp-db file
> could do the trick (although it would probably not be optimal), it
> might be useful to add a hook at the point of $wpdb assignment, to
> facilitate overrides by plugins rather than having to replace and/or
> modify the core files.
>
> I also imagine that there would have to be some performance trade-offs
> with doing it that way; specifically involving potentially rewriting
> every query (with regex, etc.) before it's executed.
>
> Support on an "equal" level would probably be more complicated, as it
> should involve replacing (or at least adding specific replacement
> hooks for) any vendor specific SQL throughout the app.
>
> The latter might be quite the undertaking, but I could see the value
> in it. It would be especially useful to already have in place if the
> situation ever came up where PGSQL (or any other DB) releases a new
> version that breaks all speed records and becomes the clear choice for
> performance, etc.
>
> Whether that (and portability in general) is enough to justify all the
> work required to get there is a matter that lots of people would
> probably have strong opinions on, on both sides of the issue.
>
> For me, it comes down to two things: (1) cost / benefit analysis (are
> the potential gains worth the extra effort), and (2) would these types
> of changes (to the core code to better facilitate portability) be in
> line with the vision of the core devs.
>
> The second will greatly impact the first. I'd be interested in helping
> out with the changes just for the fun of it, but if the consensus is
> that we don't want to go there (in core), it probably wouldn't be
> worthwhile to prepare all the patches, etc.
>
> - Jared
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>