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

The latest mysql build (5.0.3) now supports standard backslash behavior,
using the below config option.

set-variable=sql-mode=PIPES_AS_CONCAT,ANSI_QUOTES,NO_BACKSLASH_ESCAPE

PG seems to be the last holdout. :-)

Ken

Ken Johanson wrote:
> [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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>
>