PostgreSQL

I would like to see ADODB support.. I just ran into a wall with the IT dept at my firm.. I (web design dept)build in php/mysql.. the IT dept are all asp/mssql dudes.. and the refuse to run mysql on the production(live) server.. So i need a way to intergrate wordpress and mssql.. can anyone point me in the right direction?
Joshua, Thanks

Well, put me down as yet another who has been avoiding WordPress because of the lack of PostgreSQL support. As someone else said, I’ve looked at it several times and really want to use it, but I already run several PostgreSQL databases and really want to avoid dealing with MySQL.
In fact, I just examined and tossed PostNuke for just that reason: It only supports MySQL (despite having Adodb embedded in it, it hardcodes MySQL support; when I saw that, I uninstalled it).
I really like the look of WordPress and very much want something to replace the heavily license-encumbered Moveable Type that I’m currently running. Too bad it doesn’t support more than MySQL. I would happily toss in $25, myself, if PostgreSQL support were to suddenly appear…

I too am looking for PostreSQL support for WordPress.

You guys clearly need to pay more attention ??
https://wordpress-pg.sourceforge.net/
I ported 1.2 by hand myself, and with William Carrel’s help we’ve got 1.2.1 running and have done some work on current CVS (though it’s far from working, we’re both busy). My port’s been around for a while, and linked on this board too ;).
Any donations are very much appreciated. I’m a poor student that can’t afford to renew his domains.

Well, yeah, I took a look at your port. That’s what I don’t like about it: It’s a port. It means that as WordPress went forward I would be dependent on you (or, I suppose, myself, if I wanted to take the time, which I don’t) to re-port it. The idea is for WordPress to support PostgreSQL (and other DBs) directly. At the moment, though, I’m sticking with my current plan, which is to continue to use MT 2.661 until it becomes too painful to continue.
I do wish WordPress directly supported other DBs than MySQL. Unfortunately, it’s not the only one with this problem.

Definitely agree with you on that one. Fact is, the WordPress code doesn’t do any sort of DB abstraction whatsoever; and doesn’t even attempt to be database independent. I had begun designing a new database access class for the whole of WordPress, but I simply haven’t had time to go any further than a preliminary design. The developers themselves don’t seem to care about the issue and after discussing it at length, I doubt they’d be behind any sort of change in that direction. My plan was to do all of the (huge amount) of work myself, along with any supporters I could gather from the IRC channel and mailing lists, and get something working to present to them.
A good example of why DB stuff should be abstracted and as independent as possible from the start, I’d say. But hey, it’s PHP, we can’t expect intelligent design now can we :P. (I find the tagline ‘code is poetry’ at the bottom of this page slightly ironic, the WP code is not elegant nor well designed)
It’s too bad the port’s not useful to you, but it’s the best it’s going to get for the time being. I may try to get some movement going on my original idea over the winter break, but I expect to be exceedingly busy.

fmayhar – Well I guess if someone else’s (error404’s) hard work that you can obtain for free isn’t good enough for you then you’ll just have to do some work yourself – oh, you don’t want to do that either well I guess your options for free development which is suitable to your requirements is going to be a long time coming.
If you don’t appreciate error404’s work you don’t have to use it. Feel free to continue as you’re doing now.
I for one can’t use error404’s work either but I am very greatful that he’s done as much as he has. If I had the money, I’d pay him for what he’s done so far despite the fact that it’s no use to me because he’s done it for nothing and he’s giving away his work I imagine he has bills and expenses too.

Work has been done in 1.3 to clean up the messy installation. A little work to consolidate some of the DB manipulation and remove some MySQLisms has also been done. For the most part, however, DB abstraction has been put off until after 1.3. error404’s work will be very useful once we attack this in earnest. For those asking for PEAR::DB and ADODB, realize that these are 50% and 100+% the size of WP. They are large dependencies. Further, any abstraction layer will require accompanying work to make the SQL portable. error404’s work looks like a good way forward.

Good to hear that, it’s been a few months since I’ve checked out 1.3. I definitely have to reexamine where the DB code is going and plan accordingly; all that’s really necessary is for all the calls to mysql_* to be pulled out into a seperate file, which can be selected in the configuration. Then it’s a comparitavely simple matter for someone to replicate the schema and port only the centrally-organized SQL.
Definitely nice to see the development team making an effort to move forward on it. SQLite support would be nice for many as well, I imagine, and I’d be willing to write it if the SQL were more centralized, even ignoring the real abstraction issues.
ADODB would be nice for other reasons, but it wouldn’t be *that* much work to replicate the features we actually need.

I’m glad to hear that things are going forward. For my needs, ADODB would be overkill; I just need a way to use my existing PostgreSQL installation. I suspect that most feel this way: the details don’t matter as long as it works. ??
(Responding partly to Mr. Anonymous up there.) Unfortunately I simply have neither the time or the interest to help out technically in this. I have a Real Job that demands my time, and any “free” time that I may have left over from that or my family goes to kernel work, which is what I <i>am</i> interested in. But I do value your work and by no means intend to imply that it was in any way a waste of time or useless. It’s just not suitable for my needs.
And I have been known to toss a few bucks toward worthy causes when I have it to toss.
Thanks for the responses. I’ll keep an eye on WordPress as it evolves…

i agree with the above posts. i looked into porting the db to a hacked version of the SQLite ezSQL script. however, many queries throughout are quite cluttered with mySQL-specific language. peardb is perfect for a wp-type application, but right now the wp codebase is not in any type of condition to support it without a major overhaul.

Here’s another request for POSTGRE.

I started a page on the new WordPress MediaWiki, summarizing points discussed on this thread:

https://codex.www.ads-software.com/Database_Support

We should get together a battle plan, and actually get the dirty work done and make this happen. If we can figure out a bomber solution, the developers would probably do it (especially if people can contribute good code and maybe a few of those promised donations).

Yet another place I hadn’t seen yet. ?? This is a bit of a novel given what’s been said so far, so bear with me. I’m the other developer besides error404 on WordPress-Pg. My work is continuing on the WordPress-Pg 1.5 port at this time. It’s been a fair bit of work to say the least and the progress is lots of small victories.

The talk of going to some sort of large generic object persistance layer or database abstraction tool is most likely not going to work out in the long run. Such things tend to bloat and slow down your program. Given WordPress’s necessarily interactive nature such slowdowns would be bad. I imagine many are thinking like Dr. Venkman, “I’m fuzzy on the whole good/bad thing. What do you mean ‘bad’?” I’ve already observed some performance issues with the number of queries and the load generated on modest servers, to add more would really grind everything down to a halt. It doesn’t help that PHP isn’t exactly the fastest language on the block.

That said, I think there is room for database abstraction, if for no other reason so the code streams can come together at some point to satisfy many users like fmayhar (and myself) who think that vendor lock-in is bad. As an added benefit when things like “Getting the most recent N posts and the number of approved comments for each” can become a function call that looks at some global “what database are we using” setting, they can be optimized on certain databases that only need one roundtrip to get that particular bunch of information (subqueries are good) as opposed to N+1 query roundtrips. I certainly plan on coding in that direction after the 1.5 port is more or less together, although I’m uncertain how receptive the existing WordPress maintainers will be. Maybe they’ll take my patches if I send them some beer… ??

I too would like postgres support. I’d even help to add said support if I knew it would be added to the main tree.

I like the idea of going with a full abstraction layer (ADOdb being my favourite). Why, over a custom written one? Because it’s already there and it supports lots of databases.

Is the size issue really a problem? If it was a 10MB dependency I could understand the issue. But it’s <1MB uncompressed, probably smaller once you had gone through and removed some extra un-needed stuff (such as tests and performance monitoring).

Sure it’d break things like 3rd party plugins, but the longer we wait before we do something, the more plugins it will break when we finally do.

You can’t please everyone. I suggest someone just makes a choice and we stick to it, seems as though politics are the main thing holding this back.