Re: Possible to run the server with ANSI/ISO string - Mailing list pgsql-general

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

My guess is that it is worth it, if the users are given the discretion
of treading that water.. and to save them future pain by encouraging
them to migrate toward 'other-db' compatibility (or merely to migrate to
PreparedStatement to eliminate worry and *insure* interop).

But where things are right now, I *know* allot of apps specially coded
for PG (or mysql) --- using functions like PHPs escapeCslashes()... so
they are NOT compatible apps with other DBs. So making the change would
at least raises author awareness to use PreparedStatements instead (half
the battle is won then because when a PS admin turns on the new escape,
their apps still works correctly), or stop using escapeCslashes in favor
of a sql-escape function (yes, not 'old pg' compatible, but be able to
claim interop with other dbs).

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

As was mentioned earlier, this may not be too much of an issue if the
new drivers supported an option in the getConnection call that turned on
the new escape, otherwise leaving old escape turned on by default. Sort
of like the jdbc version/conformance level that jdbc drivers can report
through function calls. In fact PG could forever use the old style
escapes by default, except when a modern driver connected to it and they
both agree to use the new style.

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

Yes - and your app would be inter operable with Oracle, Sybase, etc and
have a wider audience (moot point if you use prepared statements
obviously) especially in the enterprise... Very worthwhile, imo.

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

Sorry, I misunderstood. Your point is well taken, and I agree.

Thank you,
ken