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

Re: PG 9.0 and standard_conforming_strings

From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alex Hunsaker <badalex(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 9.0 and standard_conforming_strings
Date: 2010-01-30 14:55:01
Message-ID: 4B644845.6030609@timbira.com (view raw or flat)
Thread:
Lists: 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/

In response to

Responses

pgsql-hackers by date

Next:From: Tim BunceDate: 2010-01-30 15:49:43
Subject: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Previous:From: Tim BunceDate: 2010-01-30 14:51:22
Subject: Re: Package namespace and Safe init cleanup for plperl [PATCH]

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