[wp-hackers] PostgreSQL port status?

[Otto]

Well, as has been stated before (somewhere...), patches that moved any
sort of database stuff into wp-db.php would likely be very welcome.


On 9/30/07, Computer Guru <computerguru at neosmart.net> wrote:
> 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
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>