[wp-hackers] PostgreSQL port status?

[Christine Davis]

One of the other times the topic came up (Hah.  October last year,
actually);  Matt said, among other things...

It's theoretically possible, and even attractive if you imagine *how
much larger* our userbase could be if we simply supported every
conceivable server configuration, but at some point the costs add up:

1) Infinitely more complex testing (we have enough trouble with W/LAMP)
2) Same for debugging
3) Non-trivial overhead in code
4) Much slower development (WP Vista in 2008!)
5) No visible benefits to regular users

I will be the first to admit that it is entirely luck that WP happens to
be attached to the most popular and fastest growing database in history,
and written in the most successful server-side scripting language, but
let's not throw away so lightly the benefits to development the
luckiness in our platform choices provided.

This is one of those things which keeps coming up over and over again on
this mailing list; which is probably why you aren't seeing a lot of core
devs....

On 10/1/07, Jacob <wordpress at santosj.name> wrote:
>
> 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
> >
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>