There's certainly two perspectives to this. The one you present is certainly valid, but consider the bigger picture...I'm a little worried about PostgreSQL having the same problems as PHP. In PHP, every time you want to download an application, you never see "This application works on php 4+". Instead, you see "This application works on php4+ with the following config options set <long list>". Sometimes these applications have conflicting requirements. From an administrator's standpoint, it's a mess.
In PostgreSQL I think it would actually be much worse. Right now many applications build a PostgreSQL layer, but will they build two? I think this would cause a divide in the application support (some for config option A some for config option B) in the already smaller-than-we'd-like set of software that supports PostgreSQL.
Regards,
Jeff Davis
"This application requires the following databases: Oracle versionX, MY SQL version X, Mysql version 5.2 with the no-backslashes option, UltraDB version x"
Notice the lack of PG - some apps - most notably commercial ones - will automatically shoot it down if it cant meet certain language requirements. The database itself could meet the latest SQL03 (or whatever we're up to) specs for Object Relational stuff, etc to the tee. The JDBC driver could meet the JDBC spec to the tee for transaction support, etc - but this one low level problem is a total show stopper, because it plainly breaks queries sent through various interfaces in various drivers.
Besides, the version-deprecation / version requirements you mention exists in every piece of software I've even seen. Sometime they're okay with a really old version, sometime only the newest will do. This is the very argument for getting PG to offer an (use-optional) escape behavior inline with the rest - to mitigate these version requirements down the road.
Thoughts, ken
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
