Re: [PATCHES] Escape handling in strings - Mailing list pgsql-hackers

From Robert Treat
Subject Re: [PATCHES] Escape handling in strings
Date
Msg-id 200506181007.54339.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: [PATCHES] Escape handling in strings  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [PATCHES] Escape handling in strings
List pgsql-hackers
On Friday 17 June 2005 08:55, Bruce Momjian wrote:
> Michael Glaesemann wrote:
> > On Jun 17, 2005, at 4:34 PM, Greg Stark wrote:
> > >  And for an app issuing
> > > hundreds or thousands of queries per minute (or even second) a
> > > warning could
> > > effectively be a showstopper. It could require disabling all
> > > warnings in their
> > > config to avoid filling their disk with Postgres logs in minutes.
> >
> > Good point.
> >
> > > I would suggest this warning be disable-able with a GUC variable.
> > > Otherwise
> > > you're effectively giving no advance warning time to those users.
> >
> > Perhaps NOTICE would be better, at least for the first step? People
> > might be more comfortable with that, as using backslash escaping
> > isn't really going to cause problems with this particular version,
> > but rather for future versions.
>
> I am thinking changing the level of the message isn't going to help
> people much because it still displays and fills up the server logs.
>
> > > If postgres keeps advancing at the pace it's advancing now I might
> > > suggest
> > > waiting two release cycles instead of just one.
> >
> > How's this for an idea?
> >
> > Step 1 (8.1) NOTICE level (or some other level, lower than WARNING),
> > E'' and \' are available
> > Step 2 (8.2?) WARNING level, E'' and \' are available
> > Step 3 (8.3? 8.4?) E'' available, plain '' interpreted literally.
>
> Right now I am thinking we would have the warning available in 8.1, but
> not turn it on by default.  Perhaps we can tell users to enable the
> warning at some time during 8.1 so they are ready for it in 8.2.
>

I think it is worth restating in stronger language, the potential overhead of 
raising notices or warning in such a large number of queries will be an 
upgrading show stopper for some people.  (To the extent that for some, the 
release where this is a mandatory warning will be as much a show stopper as 
the release where the behavior is changed)

IMHO we need at least 1 release with a GUC to control the warning (defaulting 
off initial, if people want the next release to default on, thats ok, but is 
probably a waste), so that people can turn it on/off in order to debug thier 
applications and make them compliant for upgrading to the next version.  It 
doesnt much matter to me where you put this... 8.0.x, 8.1... it's just a 
question of where do you want to create a roadblock to upgrading, because the 
release where you force the warning always on your going to have raised the 
barrier to entry too high for some people.  

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Returning Composite Types from C functions
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] default database creation with initdb