PG 9.0 and standard_conforming_strings
in [PgSql]
|
Prev: [HACKERS] PG 9.0 and standard_conforming_strings
Next: Package namespace and Safe init cleanup for plperl [PATCH]
From: Andres Freund on 29 Jan 2010 18:15 On Friday 29 January 2010 23:54:15 Tom Lane wrote: > Andres Freund <andres(a)anarazel.de> writes: > > What about anouncing in the 9.0 releasenotes that it will be removed in > > 9.1? > > That seems quite useless. > > I note that we've made such statements before and not followed through > on them; one that just came up again is that contrib/xml2 is a couple > releases past when it was said it'd be removed, and there is still no > prospect of it really dying in the near future. > The bottom line is that these sorts of changes take actual *work*, > and not a trivial amount of it. No amount of blather in the > documentation will substitute for somebody doing the work. It is not about somebody doing the work, it is about lowering the impact a bit. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 29 Jan 2010 18:56 > 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? Oh, yeah. I was just thinking about the direct user and DBA issues; of course if there's additional potential breakage, we'll have to defer it. Too bad, it would have been a good time to break it from a user perspective. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Jan 2010 18:59 On Fri, Jan 29, 2010 at 5:44 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Bruce Momjian <bruce(a)momjian.us> writes: >> Well, since I asked in April of 2009, at the beginning of the cycle, 6 >> years after the introduction of the variable, and we still are not doing >> it, then let's stop pretending we will ever do it. > > We have made forward progress since that thread (we fixed the plpgsql > parsing issues, partially in 8.4 and completely for 9.0). This is a really good argument. If there are changes in 9.0 that are designed to mitigate the impact of this change, then we should wait at least one or two more releases before doing anything. I say, let's plan it for 10.0. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andres Freund on 29 Jan 2010 19:31 On Friday 29 January 2010 23:47:22 Bruce Momjian wrote: > Andres Freund wrote: > > On Friday 29 January 2010 23:34:09 Tom Lane wrote: > > > Josh Berkus <josh(a)agliodbs.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. > > > > > > 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. > > > > What about anouncing in the 9.0 releasenotes that it will be removed in > > 9.1? > > You mean turned on by default, right? Obviously, yes ;-) Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: =?ISO-8859-1?Q?C=E9dric_Villemain?= on 29 Jan 2010 20:08
2010/1/29 Tom Lane <tgl(a)sss.pgh.pa.us>: > Josh Berkus <josh(a)agliodbs.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(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |