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

>>Uh, yea, this is going to require quite a bit of discussion in the
>>group, and I am concerned how it will affect other apps using
>>PostgreSQL. (The mode isn't going to be useful if it breaks plug-in
>>extensions and stuff.)
>>
>>
>
>The hard part of this isn't turning off backslash quoting; the code
>changes to do that would be pretty trivial. The hard part is not
>breaking vast quantities of existing client code. After our experience
>with autocommit, no one is going to want to solve it with a GUC variable
>that can be flipped on and off at random. That would make the
>compatibility problems that autocommit caused look like a day at the
>beach :-(
>
>I don't actually know a way to solve this that wouldn't impose
>impossible amounts of pain on our existing users, and I'm afraid that
>I rank that consideration higher than acquiring new users who won't
>consider changing their own code.
>
>If you can show me a way to provide this behavior without risk of
>breaking existing code, I'm all ears.
>
> regards, tom lane
>
>
I feel somewhat confident (very actually) that a config option that
disabled the backslash behavior globally(*) would be acceptable, BUT
leave the current backslash behavior turned on by default so that
current users are not impacted at all. Only a conscientious decision by
the db admin to turn it on could cause problems, but _only_ if he/she
didn't warn all his/her users beforehand of the impending change and its
consequences (rtm).

(*Or if it's possible, provide the no-backslash config on a per-catalog
basis perhaps? -or even per-user/group?, --that would allow individuals
to use the legacy mode until they choose otherwise)

I can say, that I for one would enable the no-backslash config option
out of the box -globally -so that we can start using pg now without any
more upper managerial concerns/excuses about language/interface
compliance..I can also say that (what we already know) the longer we
wait to provide the 'right' option, the *more* legacy apps (and
interfaces) will be built around it and consequently suffer when the
need for change eventually comes (almost wholly caused by interop
concerns). And market gain is being hurt now by this incompatibility
with commercial offerings; that's an unfortunate fact.

Better to nip it in the bud sooner than later, imo.

thoughts,
ken