Re: escape string type for upcoming 8.1 - Mailing list pgsql-general

From Ken Johanson
Subject Re: escape string type for upcoming 8.1
Date
Msg-id 435FABE5.4040105@kensystem.com
Whole thread Raw
In response to Re: escape string type for upcoming 8.1  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: escape string type for upcoming 8.1  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
Bruce Momjian wrote:
> E'' is more a marker than a type.  I realize making E a type might work,
> but it seems unusual.
>
> What we could do is backpatch E'' to 8.0.X as a no-op like it will be in
> 8.1.
>

Bruce,

Is it possible in the 8.1 betas to 'switch on' on the standard SQL
escape behavior? This is from the use-case perspective of someone who
does not have backwards compatibility concerns, rather, I'd like to
preemptively forward-port / certify an app from another databases, onto
PostgreSQL -- so all I need to do is switch that config on, if possible.

 From the changelog:

"While this release does not change the <default?> handling of
backslashes in strings, it does add new configuration parameters to help
users migrate applications for future releases:

o standard_conforming_strings ......

o escape_string_warning ......

The standard_conforming_strings value is read-only. ...."

The last quoted sentence seems to answer my question (as no), but
hopeful optimism is my motto :-)

If it is indeed readonly, can it be made 'writable' before the 8.3
release where is would be made the default behavior? For that matter, if
the current backslash behavior stayed as the default for pre-8.3
releases, and the patches are backported, I don't see any harm to the
old-style apps/users; yet the correct behavior option is a useful
"opt-in" one (one that I would like to try, now, even on 8.1).

Thank you,

    -Ken



pgsql-general by date:

Previous
From: "Andrus"
Date:
Subject: Re: Why database is corrupted after re-booting
Next
From: Scott Marlowe
Date:
Subject: Re: Why database is corrupted after re-booting