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.
#26
http://www.postgresql.org/about/news.1108 do we still want 8.3 only?
#27
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.
#28
"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.
#29
Surely procedures are only for postgresql driver so if the pgsql maintainers find it useful...
#30
Debian lenny ships with 8.3. I want to stay with versions of PostgreSQL that are commonly supported. So lets stay with 8.3
#31
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?
#32
@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?