Re: PG 9.0 and standard_conforming_strings - Mailing list pgsql-hackers

From Euler Taveira de Oliveira
Subject Re: PG 9.0 and standard_conforming_strings
Date
Msg-id 4B644845.6030609@timbira.com
Whole thread Raw
In response to Re: PG 9.0 and standard_conforming_strings  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: PG 9.0 and standard_conforming_strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PG 9.0 and standard_conforming_strings  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
Peter Eisentraut escreveu:
> Maybe the next step should be to leave standard_conforming_strings off
> but make the warning an error.
> 
It will break application in the same way as enabling the parameter. Besides
that the parameter should be renamed to escape_string_*error* to reflect the
fact that it doesn't emit an error anymore. I don't think it is a good idea.

The main problem of enabling standard_conforming_strings is that applications
and/or programming language DB APIs are not prepared to support this. I don't
see a change in DB APIs (that I know of -- Python, Perl, and PHP) to add
support for producing a string according to standard_conforming_strings parameter.

IMHO we need to encourage such languages to modify their functions so we can
produce strings according to this parameter. These change will minimize the
number of problems in applications. Of course, there will be some problems in
those applications that doesn't use the escape function of the DB API but they
could always disable this parameter. ;)

As for enabling it by default, I'm afraid we will have to wait a few cycles of
development because of those changes in DB APIs. A reasonable target is 10.0. ;)


--  Euler Taveira de Oliveira http://www.timbira.com/


pgsql-hackers by date:

Previous
From: Tim Bunce
Date:
Subject: Re: Package namespace and Safe init cleanup for plperl [PATCH]
Next
From: Tim Bunce
Date:
Subject: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]