In our discussion about what would be included in CMSMS 1.11 the topic of database support has come up.

Officially, the CMSMS core always has, and still supports Postgres (at least postgres 8 ). We rarely see any complaints from people that use CMSMS with postgres, however those few that do complain tend to be loud and vocal

The dev team tests and fixes bugs wrt postgres as an afterthought (simply because none of the dev team use it on a daily basis). We also know that many modules will not work 'out of the box' with Postgres. largely for the same reason, the developers don't use it.

But since we're in this decision making process, and we had no real (scientific or otherwise) statistic to tell us exactly what portion of our user community uses CMSMS with Postgres, we thought we'd put it out to the community to give us some feedback.

This poll will run for about 30 days, and I hope that we get enough information that we can make an informed decision about postgres, rather than a decision based on our casual observance. So please respond.

Thanks

The Dev Team.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

I've used Postgres in the past... I don't really have any active CMSMS sites at the moment though.

Does it mean next CMSMS version will not use adodb lite?

Is there any advantage of ADOdb any more, now that PDO is built-in to PHP? I haven't used it for a while so don't know if it's changed much in the past few years.

No, it does not. Even if we were to decide to drop support for postgres, if we dropped adodb_lite and went with some other abstraction library we would instantaneously break each and every module that is stored in the forge, along with alot of the UDT's. and many plugins. That's just not feasible.

What it would mean, if we decided to drop postgres support; would be that we could then delete one file from the distribution (the adodb_lite postgres driver). And then not worry about finding somebody to test CMSMS with postgres, or setting up another database, and a duplicate environment of CMSMS just for testing postgres. We could also ignore any bug reports that happen to come into the forge or forum related to postgres.

On a related subject: Without getting into the religious debate about performance and whether 0.01% of a performance gain, or 1000 bytes is important enough to consider rewriting thousands of lines of code. I have looked through the adodb_lite code, and done some hours researching the issue... and relatively speaking, with the exception of one thing the adodb_lite library is fairly light weight, and efficient. Also, we've already tweaked it and trimmed it down a fair bit. That 'one thing' is that it uses some trickery for multiple inheritance because of the PHP4 era that it was written in.

To answer the next question: Yes, it is possible to morph adodb_lite into something that uses PHP5's OOP capabilities so as to not break all of CMSMS code... but would it really gain us that much performance? would it be worth the effort? I don't know. There are bigger performance fish to fry before we go down that road.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

In a word, the answer is 'no'... but in many ways we're stuck with the adodb interface. Unless of course we want to break everything, and re-do it.

Though I do kinda like the adodb datadictionary stuff... and at one time I was looking at finding/implementing an adodb library for sqlite3... but sqlite3 has a few missing key features that shot that idea down for me. Again, though I could've worked around those issues it made it 'not worth the effort'.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

Don't waste time on Postgres db. Only really geeks are still using it. No offence.

Since dev time is limited, focus on one thing only.

Thx for the clear answer ...

Hello,

We use CMSMS with Postgres for two years. We use Postgres to manage a big weather database, so it's easy for us to maintain only one database system. I hope you'll still support Postgres in the future...

Pam.

Just bumping this so that people read it and vote.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

If it isn't that much work to keep Postgres, keep supporting it for those people who are using it. If it takes a lot of time, then drop it. As already writen in this poll, there are other issues that need more attention. I think a big issues is the fact that there is no desent wysiwyg editor default with the installation.

If there are no postgres professionals for development AND support inside your team support should be removed.

The current situation casts a bad light to CMSMS.

This topic was interesting... not only because there were a low number of votes (which to me indicates general lack of interest, or lack of understanding)... but because of the range of those votes.

Indeed more people answered the poll with 'What is postgres?' than those that indicated that they used postgres with CMSMS full time. And the vast majority voted that although they knew what postgres is, had no intention of using it with CMSMS anyways. These two poll questions made our decision simple.

The decision: The dev team decided that we will be dropping support for postgres as of CMSMS 1.11. This does not mean that we will be dropping the adodb library (there is just too much of an investment and risk to drop that library). However we'll be removing the postgres support from that library and from the installer etc.

The CMSMS Dev team, and all module developers should continue to write their code using the adodb interface (even if they only support mysql for their modules) and in a database agnostic manner, to consider the future possibility that we add support for another database scheme (like as mentioned earlier sqlite, or pdo, etc).

Thanks for your time and cooperation.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

I use both on different sites. mysql is surly the most common, and default database, and next to it i would see the support of sqlite3 appreciated. But please don't simply drop the support of psql. If the development was slow because of the less feedback, it's OK. I don't know the inner core of the CMS that good, but is it possible to have the choice of database left to the choice of an implementation of an abstract class?
Then there could be a Plugin-Team supporting psql or other strange alternatives.

Will we get ADOdb lite (very old version from 2007-01-12) again or current PHP5 related ADOdb full (version from 2011-09-08)?