We've upped MySQL requirements to 5.0, how about postgres?

Comments

sammys’s picture

Status: Needs review » Reviewed & tested by the community

Since we're moving MySQL up to 5.0 there's no reason for us to support 7.4 PostgreSQL anymore especially because transaction support will be much nicer in PostgreSQL 8.x and beyond.

Any complaints? Voice them now!

damien tournoud’s picture

Ok for the principle. I even suggest we recommend the latest stable version (ie PostgreSQL 8.3, as of today).

We should also add that requirement to the INSTALL.TXT file.

catch’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new629 bytes

Re-rolled for 8.4.

catch’s picture

StatusFileSize
new629 bytes

Umm. 8.3

Crell’s picture

I have no idea what the distribution of Postgres installations is or what the support cycle is for older versions of Postgres. However, I am all in favor of supporting fewer versions of a database so that we have fewer bugs to work around. :-) D7 does sound like the time to do it, too. The only copy of Postgres I have available to me is 8.3. So I'm +1 on upping the requirement to, um, whatever. :-)

bjaspan’s picture

I developed and tested Schema API for pgsql 8. It's possible we already don't support 7.x.

linuxpoet’s picture

7.4 is likely to be EOL by the end of the year. I would actually suggest having a requirement of 8.1 as 8.1 is the first release that has two very important technologies:

PITR
Partitioning/constraint_exclusion

As well as several specific performance enhancements.

catch’s picture

StatusFileSize
new629 bytes
new629 bytes
new629 bytes
new629 bytes

Here's the patches. One of them has to be RTBC ;)

david strauss’s picture

+1 on dropping support for PgSQL 7. We already have enough trouble finding testers for any version of Postgres. Plus, Postgres users are unlikely to be on cheap shared hosting where they're locked into an old version.

naheemsays’s picture

From what I can see, RHEL/Centos 5 comes with version 8.1, so that may be a good minimum target. (but then again, it has php version 5.1.6+patches too... potentially not meeting the php requirements.)

Crell’s picture

Status: Needs review » Reviewed & tested by the community

Debian Stable (Etch) currently ships with both 7.4 and 8.1.

The now-retired Ubuntu Edgy also offers both 7.4 and 8.1, so I think it's a safe bet that Hardy (the current stable LTS release) offers at least 8.1.

It sounds to me like 8.1 is a safe version to target, as all of the majors support it already. I am marking this RTBC for the 8.1 patch in #8.

chx’s picture

Another vote for 8.1 -- if we are bent on supporting pgsql then be it 8.1.

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed the 8.1 patch to CVS HEAD. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

catch’s picture

Title: Require PostgreSQL 8 » Require PostgreSQL 8.3
Status: Closed (fixed) » Active

Since there are significant differences between < 8.3 and > 8.3, and we have limited resources for supporting postgres amongst core developers, I think we should up the requirements a notch further. It's reasonable to expect that people running Drupal on PostgreSQL aren't doing so on random shared hosting accounts.

damien tournoud’s picture

Title: Require PostgreSQL 8.3 » PostgreSQL surge #7: Require PostgreSQL 8.3
Status: Active » Needs review
StatusFileSize
new631 bytes

Here is a patch for review.

alexanderpas’s picture

Keep requirement on 8.1 as per #11

hardy does 8.1 too!

damien tournoud’s picture

- Debian Etch default to 7.5.22, but has a supported backport of 8.3.5
- Ubuntu Hardy has both 8.2.7 and 8.3.1

I see no reason not to concentrate on 8.3 at this point.

catch’s picture

Ubuntu Intrepid is out, and ships with 8.3 - http://packages.ubuntu.com/source/intrepid/postgresql-8.3

There's a decent chance that Debian Lenny will be out before Drupal 7 - and that also ships with Postgres 8.3 - http://packages.debian.org/lenny/postgresql

alexanderpas’s picture

my mistake...
+1 on 8.3

chx’s picture

Status: Needs review » Reviewed & tested by the community

Well, that makes a lot of sense. This halves the testing necessary for postgresql and as said, when you have so little resources it helps to keep a sharp focus.

Crell’s picture

I can go either way here. However, since I think it's a fair bet that anyone running Postgres is also running their own server we have a lot more flexibility in what we require than we would with MySQL or SQLite. So I'm cool with this too.

dries’s picture

Status: Reviewed & tested by the community » Fixed

Makes sense. Committed to CVS HEAD. Does that mean we can clean-up any code?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

chx’s picture

Status: Closed (fixed) » Active
chx’s picture

http://www.postgresql.org/about/press/features84.html of particular interest can be the variable number of argument procedures and AS now being optional per SQL standard.

david strauss’s picture

"AS" being optional isn't very helpful. Continuing to use "AS" for column aliases does not make our queries less portable or capable.

Procedures in PostgreSQL use a completely different syntax than MySQL's, so capabilities there cannot be used without resorting to database-specific implementations, anyway.

If these are the only two reasons why we'd bump requirements to 8.4, I'd say no.

chx’s picture

Surely procedures are only for postgresql driver so if the pgsql maintainers find it useful...

josh waihi’s picture

Status: Active » Closed (fixed)

Debian lenny ships with 8.3. I want to stay with versions of PostgreSQL that are commonly supported. So lets stay with 8.3

grub3’s picture

AFAIK, we should only support PostgreSQL 8.4.
Drupal works under PostgreSQL 8.3 but a lot contrib modules will fail.

PostgreSQL 8.4 was developed to cure this compatibility problem.

Some new features:
* GROUP BY ... ORDER BY works with one or several colums. This is how MySQL works and it solves several issues.
* Supports DELETE on multiple tables, like in MySQL.

I am a real PostgreSQL fan, but I have to say we should only support 8.4 and drop 8.3 support.

If you have a look at my bugfixes, most of them would not exist if PostgreSQL 8.4 was used.
I think we should bump compatibility to 8.4 and review remaining PostgreSQL bugs.

So let's migrate to 8.4. Can we?

dave reid’s picture

@jmpoure: I don't think you know how the issues queue work. This issue has been closed for almost a month now so not many people are going to notice it. Maybe you should join the http://groups.drupal.org/postgresql group to discuss such things first?