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: Bruce Momjian on 29 Jan 2010 16:06 Tom Lane wrote: > Alex Hunsaker <badalex(a)gmail.com> writes: > > On Fri, Jan 29, 2010 at 13:42, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> [ still bearing scars from the 8.3 implicit-cast business, which we > >> didn't think would generate nearly the backlash it did... ] > > > Yeah that was my first reaction. But then again we also have a guc > > they can change back. > > "There's a GUC for it" is NOT a helpful answer; if there's one thing > that we've learned the hard way over the past years, it's that GUCs > don't solve compatibility problems. Applications don't know to set > them, and having the wrong setting can easily become a security hole > (particularly for this one). > > I stand by the position that it's way too late in the cycle for > insufficiently-thought-out proposals for major behavioral changes. 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. The way the docs stand now we hold it over people's heads and issue warnings that are meaningless if we are never going to change it. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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: Alex Hunsaker on 29 Jan 2010 16:16 On Fri, Jan 29, 2010 at 14:03, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Alex Hunsaker <badalex(a)gmail.com> writes: >> On Fri, Jan 29, 2010 at 13:42, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > I stand by the position that it's way too late in the cycle for > insufficiently-thought-out proposals for major behavioral changes. After skimming the thread Bruce linked: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php It certainly seems "insufficiently-thought-out". :( -- 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 16:20 > 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 people who read -hackers have been using standards-conforming-strings for years. Further, if we announce it now, people have 4-5 months to get ready for it, assuming they were updating to 9.0.0 anyway, which I doubt anyone is. For this release, I'm already planning to have big "backwards compatibility" section and web page with *lots* of warnings and explanations, and because of the media around the release for once it will be read. I'd argue that Bruce is right; if we're not going to do it now, we might as well stop pretending we ever are. --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: Bruce Momjian on 29 Jan 2010 16:24 Alex Hunsaker wrote: > On Fri, Jan 29, 2010 at 14:03, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Alex Hunsaker <badalex(a)gmail.com> writes: > >> On Fri, Jan 29, 2010 at 13:42, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > I stand by the position that it's way too late in the cycle for > > insufficiently-thought-out proposals for major behavioral changes. > > After skimming the thread Bruce linked: > http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php > > It certainly seems "insufficiently-thought-out". :( Is this still true? When we changed plpgsql so it shared the scanner with the backend scanner, does this issue no longer apply, i.e. consider honoring standard_conforming_strings in PL/pgSQL function bodies? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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: "Kevin Grittner" on 29 Jan 2010 16:32
Alex Hunsaker <badalex(a)gmail.com> wrote: > After skimming the thread Bruce linked: > http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php > > It certainly seems "insufficiently-thought-out". :( Just as a clarification, while the GUC was *added* in 8.1, it was read-only with a value of 'off'. I submitted a patch and started using it under 8.1 in February of 2006 (because we had an urgent need), and it officially became *settable* in 8.2. I don't have strong feelings about changing the default. Obviously, this bites people primarily when converting to PostgreSQL -- that's when it bit me and that's where people normally are when they post to the lists about related issues. It's not clear to me that the issues related to functions have been thought out sufficiently; my personal feeling is that a function should run with the setting under which it was created (as the semantics of the literal seem as though they should be "frozen" at that point), but that was shot down. And then there's the issue about EXECUTE. If we don't have consensus on a solution to those issues, maybe we should wait. Those who need it who are already using PostgreSQL already have it figured out -- it's just a bump on the road to converting for those used to standard literals. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |