Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
     subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
     message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux