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

Re: PG 9.0 and standard_conforming_strings

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Alex Hunsaker <badalex(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 9.0 and standard_conforming_strings
Date: 2010-01-30 01:08:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/1/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>> I stand by the position that it's way too late in the cycle for
>>> insufficiently-thought-out proposals for major behavioral changes.
>> I don't see how announcing this earlier in the dev cycle would help, at
>> all.
> We would have more than no-time-at-all to test it and fix any breakage.
> Just to start close to home, do you really trust either psql or pg_dump
> to be completely free of standard_conforming_strings issues?  How about
> JDBC or ODBC?  Python drivers?  PLs?

Do you mean that turning standard_conforming_string ON may lead to
error with pg_dump, psql or something else ? (I don't care of projects
outside the official postgresql tarball in this question)

Whether the param is ON or OFF by default, what does that change in this area ?

> The really short and sweet answer is that if you have any ambition at
> all to ship 9.0 this year, it is too late to add new work items.  This
> is a work item, and not a small one.
>                        regards, tom lane
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

Cédric Villemain

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-30 02:01:12
Subject: Re: PG 9.0 and standard_conforming_strings
Previous:From: Andres FreundDate: 2010-01-30 00:31:18
Subject: Re: PG 9.0 and standard_conforming_strings

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