Skip site navigation (1) Skip section navigation (2)

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

From: Jeff Davis <jdavis-pgsql(at)empires(dot)org>
To: Ken Johanson <pg-user(at)kensystem(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PgSQL General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Possible to run the server with ANSI/ISO string
Date: 2005-02-28 16:48:14
Message-ID: 1109609294.4089.274.camel@jeff (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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 <long list>".
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.

	Jeff Davis

In response to


pgsql-general by date

Next:From: Robby RussellDate: 2005-02-28 17:11:40
Subject: Re: GUI
Previous:From: Karsten HilbertDate: 2005-02-28 16:46:43
Subject: Re: row numbering

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group