Re: Possible to run the server with ANSI/ISO string
От | Ken Johanson |
---|---|
Тема | Re: Possible to run the server with ANSI/ISO string |
Дата | |
Msg-id | 4223511C.6080001@kensystem.com обсуждение исходный текст |
Ответ на | Re: Possible to run the server with ANSI/ISO string (Jeff Davis <jdavis-pgsql@empires.org>) |
Ответы |
Re: Possible to run the server with ANSI/ISO string
Re: Possible to run the server with ANSI/ISO string |
Список | pgsql-general |
>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 > > There's certainly two perspectives to this. The one you present is certainly valid, but consider the bigger picture... "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
В списке pgsql-general по дате отправления: