Re: Possible to run the server with ANSI/ISO string

On Mon, 2005-02-28 at 10:13 -0700, Ken Johanson wrote:
> >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 -
[snip]

A valid point: that's certainly the issue we're dealing with here.

I think most people agree that being SQL compliant is good. The question
is: is it worth the pain for existing users?

A configurable option does not make the pain disappear. Admins are
forced to choose one side (either sql compliant or c style) and exclude
the other applications. Any app developer that wants to support pre-8.1
apps will have to have a c-style app available. So even if you nip it in
the bud, it's not really gone yet because app developers want to support
old versions of postgres.

I know if we added the option and deprecated the old style, I would be
forced to choose between using deprecated syntax that may not be
supported for long, or doing a lot of work to convert and retest
applications.

> 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.

I think you may have misunderstood what I meant. I am not suggesting
that we don't change the database at all between versions, my argument
was showing the difficulties when one version has many different shapes
due to many incompatible options.

Regards,
Jeff Davis