PostgreSQL surge #7: Require PostgreSQL 8.3
catch - April 18, 2008 - 09:25
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | database system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
We've upped MySQL requirements to 5.0, how about postgres?
| Attachment | Size |
|---|---|
| postgres-8.patch | 1.06 KB |
| Testbed results | ||
|---|---|---|
| postgres-8.patch | failed | Failed: Failed to apply patch. Detailed results |
#1
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!
#2
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.
#3
Re-rolled for 8.4.
#4
Umm. 8.3
#5
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. :-)
#6
I developed and tested Schema API for pgsql 8. It's possible we already don't support 7.x.
#7
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.
#8
Here's the patches. One of them has to be RTBC ;)
#9
+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.
#10
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.)
#11
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.
#12
Another vote for 8.1 -- if we are bent on supporting pgsql then be it 8.1.
#13
Committed the 8.1 patch to CVS HEAD. Thanks.
#14
Automatically closed -- issue fixed for two weeks with no activity.
#15
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.
#17
Here is a patch for review.
#18
Keep requirement on 8.1 as per #11
hardy does 8.1 too!
#19
- 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.
#20
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
#21
my mistake...
+1 on 8.3
#22
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.
#23
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.
#24
Makes sense. Committed to CVS HEAD. Does that mean we can clean-up any code?
#25
Automatically closed -- issue fixed for two weeks with no activity.