Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
database system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
18 Apr 2008 at 09:25 UTC
Updated:
19 Apr 2011 at 09:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
sammys commentedSince 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!
Comment #2
damien tournoud commentedOk 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.
Comment #3
catchRe-rolled for 8.4.
Comment #4
catchUmm. 8.3
Comment #5
Crell commentedI 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. :-)
Comment #6
bjaspan commentedI developed and tested Schema API for pgsql 8. It's possible we already don't support 7.x.
Comment #7
linuxpoet commented7.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.
Comment #8
catchHere's the patches. One of them has to be RTBC ;)
Comment #9
david strauss+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.
Comment #10
naheemsays commentedFrom 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.)
Comment #11
Crell commentedDebian 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.
Comment #12
chx commentedAnother vote for 8.1 -- if we are bent on supporting pgsql then be it 8.1.
Comment #13
dries commentedCommitted the 8.1 patch to CVS HEAD. Thanks.
Comment #14
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #15
catchSince 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.
Comment #17
damien tournoud commentedHere is a patch for review.
Comment #18
alexanderpas commentedKeep requirement on 8.1 as per #11
hardy does 8.1 too!
Comment #19
damien tournoud commented- 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.
Comment #20
catchUbuntu 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
Comment #21
alexanderpas commentedmy mistake...
+1 on 8.3
Comment #22
chx commentedWell, 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.
Comment #23
Crell commentedI 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.
Comment #24
dries commentedMakes sense. Committed to CVS HEAD. Does that mean we can clean-up any code?
Comment #26
chx commentedhttp://www.postgresql.org/about/news.1108 do we still want 8.3 only?
Comment #27
chx commentedhttp://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.
Comment #28
david strauss"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.
Comment #29
chx commentedSurely procedures are only for postgresql driver so if the pgsql maintainers find it useful...
Comment #30
josh waihi commentedDebian lenny ships with 8.3. I want to stay with versions of PostgreSQL that are commonly supported. So lets stay with 8.3
Comment #31
grub3 commentedAFAIK, 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?
Comment #32
dave reid@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?