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  (Bruno Wolff III <bruno@wolff.to>)
Re: Possible to run the server with ANSI/ISO string  (Jeff Davis <jdavis-pgsql@empires.org>)
Список 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 по дате отправления:

Предыдущее
От: Bricklen Anderson
Дата:
Сообщение: Re: to_char bug?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: row numbering