[wp-hackers] PostgreSQL port status?

[Computer Guru]

OK, ATM WordPress is already *technically* is extendable by sticking db.php in \wp-content\

I've attached a db.php w/ the replaced MySQL functions, but unfortunately, WordPress doesn't honor its own system and has mysql_* functions hard-coded into other files.

Queries hard-coded into files I can understand, but there is absolutely no need to ever call mysql_* functions outside of wp-db.php.... everything else should use that class.

Right, so no guarantees or anything - I'm using the code from the file forwarded by usleepless for the conversion.... I have to go right now, but assuming you can get wp-setup to use $wpdb instead of its own hard-coded mysql functions (shouldn't be too hard) it should work to some minimal extent :)

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 6:29 AM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] PostgreSQL port status?
> 
> 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