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

On Sun, 2005-02-27 at 18:25 -0700, Ken Johanson wrote:
> >>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).
> 

I'm a little worried about PostgreSQL having the same problems as PHP.
In PHP, every time you want to download an application, you never see
"This application works on php 4+". Instead, you see "This application
works on php4+ with the following config options set ".
Sometimes these applications have conflicting requirements. From an
administrator's standpoint, it's a mess.

In PostgreSQL I think it would actually be much worse. Right now many
applications build a PostgreSQL layer, but will they build two? I think
this would cause a divide in the application support (some for config
option A some for config option B) in the already smaller-than-we'd-like
set of software that supports PostgreSQL.

Regards,
	Jeff Davis