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
In response to
pgsql-hackers by date
|Next:||From: Tim Bunce||Date: 2010-01-30 15:49:43|
|Subject: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]|
|Previous:||From: Tim Bunce||Date: 2010-01-30 14:51:22|
|Subject: Re: Package namespace and Safe init cleanup for plperl