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: Alex Hunsaker on 29 Jan 2010 15:50 On Fri, Jan 29, 2010 at 13:42, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > I wrote: >> Bruce Momjian <bruce(a)momjian.us> writes: >>> With the release of Postgres 9.0, should we consider changing the >>> default for 'standard_conforming_strings'? > >> I'm inclined to think we're going to have enough problems without that. > [ 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. Sure you could create your own typecasts to restore the old behavior in 8.3 (after trolling the mailing lists, or finding some blog entry that got created X months after the release...). Thats no where near as nice as a simple setting. -- 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 15:50 On Fri, Jan 29, 2010 at 3:28 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Bruce Momjian <bruce(a)momjian.us> writes: >> With the release of Postgres 9.0, should we consider changing the >> default for 'standard_conforming_strings'? > > I'm inclined to think we're going to have enough problems without that. > Changing that default will break, approximately speaking, every single > Postgres client app. Do you really think more than epsilon of them > are clean and ready for such a change? Well, I already had to fix a great many things in my apps to prevent them from spewing warnings all over creation. If other people have done likewise it might not be too bad; OTOH, there's probably not a huge amount of downside in waiting. ....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: Bill Moran on 29 Jan 2010 15:51 In response to Bruce Momjian <bruce(a)momjian.us>: > Tom Lane wrote: > > Bruce Momjian <bruce(a)momjian.us> writes: > > > With the release of Postgres 9.0, should we consider changing the > > > default for 'standard_conforming_strings'? > > > > I'm inclined to think we're going to have enough problems without that. > > Changing that default will break, approximately speaking, every single > > Postgres client app. Do you really think more than epsilon of them > > are clean and ready for such a change? > > Well, if they aren't ready now, then we might as well say we are never > going to change it and update the documentation and TODO list to reflect > that --- we have had standard_conforming_strings since 2005. We can't > keep pretending this will happen if we have no intention of doing it. Announce it as a change for 9.1 NOW, and then it will be whoever's fault if they aren't paying attention. Plenty of time to fix it if it's announced now. Also, as long as the config option is there, they can always flip it back, which makes it MUCH lower overhead than the casting change was. Overall, I don't think this change is nearly as severe as the cast change in 8.3, and I don't feel it warrants the same eggshell walking. When the decision is made to remove the standard_conforming_string config option altogether ... that'll be a different story! -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- 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 15:58 Tom Lane wrote: > I wrote: > > Bruce Momjian <bruce(a)momjian.us> writes: > >> With the release of Postgres 9.0, should we consider changing the > >> default for 'standard_conforming_strings'? > > > I'm inclined to think we're going to have enough problems without that. > > BTW, core already had that discussion, but maybe I should repeat it > to try to forestall any other "since this is going to be 9.0, let's > break backwards compatibility in a big way!" proposals. Now is not > the time to be making big changes; we are much too late in the devel > cycle to work through all the possible consequences. Because we > switched from it's-8.5 to it's-9.0 at such a late stage, we really > need to consider that that's only a marketing version number and > technical compatibility decisions should be made the same way as > for any other major release. > > Perhaps at some point we will choose to do a major version bump where > we really do clean up a lot of bad backwards-compatibility things. That > needs to be done in a deliberate fashion with a lot of advance planning; > and things should get broken near the beginning of the devel cycle, not > the end. > > [ still bearing scars from the 8.3 implicit-cast business, which we > didn't think would generate nearly the backlash it did... ] I did ask this same question for the 8.5/9.0 release in April of 2009 so don't say I am only asking about this at the end of development cycles: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php -- 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: Tom Lane on 29 Jan 2010 16:03
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. 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 |