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: "Greg Sabino Mullane" on 3 Feb 2010 13:46 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Perl (DBD::Pg anyway) has been compatible since May 2008. > I would interpret that to mean that there is a significant possibility > that a too-old DBD::Pg could get used with a new PostgreSQL, and > therefore we shouldn't change anything for 9.0. May 2008 is not that > long ago, especially for people running systems like RHEL with > five-year major release cycles. That's a silly conclusion. Applications and drivers are always going to lag behind. If someone is having a problem, they either upgrade their DBD::Pg or flip the GUC. Are you really saying we should wait until 2008 +5 years (2013!) before making this change? Wouldn't we have to wait five years past the point when *all* drivers are compatible by your definition? > I am not sure I really understand why anyone is a rush to make this > change. What harm is being done by the status quo? What benefit do > we get out of changing the default? The major argument that has been > offered so far is that "if we don't change it now, we never will", but > I don't believe that the tenor of this discussion supports the > contention that Tom or anyone else never wants to make this change. It's hardly a rush (the GUC has been around and is being used in production), and the benefit is standards compatibility, something we strive for around here. I personally don't agree with the "now or never" argument, but I do agree with the "dot zero release is a good time for changes like this" argument. > It also seems to overlook the fact that we are STILL dealing with the > fallout from this change in the core code; Tom gave examples upthread > of changes that are being released for the first time *in 9.0* to > address problems created by this transition. And that is just the > core code; we have to expect that third-party code will lag behind. Which fallout are we still dealing with? Are you saying that the developers are not up to the challenge of handling this before 9.0 is released? (If this were anything more than a simple boolean GUC fix, I would be in your corner). Yes, third-party code will lag behind, but, again, that's the nature of the game. We didn't wait for every driver, app, and script to support schemas before we added them in 7.4, for example. We certainly didn't wait for applications to be implicit casting ready before 8.3, to (over?)use another example. - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201002031342 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktpxEUACgkQvJuQZxSWSsibFwCeJzeQzUTBFwqHQ451Y23cbLfT 4UUAoK/2Sg/pxq5ipdB2B2ekfzQgW0cT =5/gh -----END PGP SIGNATURE----- -- 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 3 Feb 2010 13:48 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Tom Lane wrote: >> The argument for doing this now hinges solely on a marketing-driven >> choice of version name, and not on any actual evidence that applications >> are ready for it. We really need to do this at the start of a devel >> and alpha test cycle, not at the end. > Application writers probably didn't bother all that much with alphas > though. The bulk of them is going to start with the betas, which have > not been delivered yet, so it seems a good time to try. I still think that changing it now is going to open a can of worms that we shouldn't be opening at this stage. We have got more than enough to worry about for 9.0 already. I think it is absolute folly to believe that this is only going to be a matter of "flip the default and nothing else is going to pop up". 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
From: Rod Taylor on 3 Feb 2010 13:37 On Wed, Feb 3, 2010 at 13:20, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane <greg(a)turnstep.com> wrote: >> Perl (DBD::Pg anyway) has been compatible since May 2008. > > I would interpret that to mean that there is a significant possibility > that a too-old DBD::Pg could get used with a new PostgreSQL, and > therefore we shouldn't change anything for 9.0. Â May 2008 is not that > long ago, especially for people running systems like RHEL with > five-year major release cycles. I fall into this camp with a few machines still running standard RHEL 4 which I believe has DBD::Pg 1.32 installed. We do keep up to date with PostgreSQL but the machines connecting to it include everything from brand new web servers through to ancient machines in accounting running reports. As much as I would like GUCs to disappear I think this one should proceed cautiously and probably be a 9.1 or even 9.2 item. -- 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 3 Feb 2010 14:13 > I still think that changing it now is going to open a can of worms that > we shouldn't be opening at this stage. We have got more than enough to > worry about for 9.0 already. I think it is absolute folly to believe > that this is only going to be a matter of "flip the default and nothing > else is going to pop up". I'll support Tom on this. I'm already worried about the timeline. --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 3 Feb 2010 14:15
On Wed, Feb 3, 2010 at 1:46 PM, Greg Sabino Mullane <greg(a)turnstep.com> wrote: >>> Perl (DBD::Pg anyway) has been compatible since May 2008. > >> I would interpret that to mean that there is a significant possibility >> that a too-old DBD::Pg could get used with a new PostgreSQL, and >> therefore we shouldn't change anything for 9.0. May 2008 is not that >> long ago, especially for people running systems like RHEL with >> five-year major release cycles. > > That's a silly conclusion. Applications and drivers are always going to > lag behind. If someone is having a problem, they either upgrade their > DBD::Pg or flip the GUC. Are you really saying we should wait > until 2008 +5 years (2013!) before making this change? Wouldn't we have > to wait five years past the point when *all* drivers are compatible > by your definition? I don't think it's a silly conclusion at all, though it's possible that I am a silly person. The longer we wait before making an incompatible change, the more people will have adjusted their code to the new reality (or upgraded their drivers, etc.) and the fewer things will break. Taking this argument to its illogical extreme, we should never change anything at all, but I'm not proposing that. What I am saying is that I got all of the standard_conforming_strings problems in my own code (that I know about) fixed about a year ago, and it does not seem implausible to think that there could be people in the world who take longer to upgrade than I do. In fact, it seems overwhelmingly likely. Kevin Grittner made a good point upthread: the harm in NOT changing standard_conforming_strings is that we will endure for a longer period of time with strings that, well, don't conform to the standard, which may cause problems for people trying to migrate to PostgreSQL from other database systems. Conversely, the harm in changing it is that it may break existing PostgreSQL applications that run just fine on older releases. The second problem is something that we can expect to gradually decrease over time because of (1) the incredibly annoying escape_string_warning behavior and (2) software version upgrades. Exactly when the risk is low enough to make the change is a judgement call. >> It also seems to overlook the fact that we are STILL dealing with the >> fallout from this change in the core code; Tom gave examples upthread >> of changes that are being released for the first time *in 9.0* to >> address problems created by this transition. And that is just the >> core code; we have to expect that third-party code will lag behind. > > Which fallout are we still dealing with? Are you saying that the > developers are not up to the challenge of handling this before 9.0 > is released? (If this were anything more than a simple boolean GUC > fix, I would be in your corner). http://archives.postgresql.org/pgsql-hackers/2010-01/msg02992.php > Yes, third-party code will lag behind, but, again, that's the nature of > the game. We didn't wait for every driver, app, and script to support > schemas before we added them in 7.4, for example. We certainly didn't > wait for applications to be implicit casting ready before 8.3, to (over?)use > another example. Implicit casting was in some ways less of a big deal than this change, at least for me. It broke some things, but they all BROKE, and then I fixed them. When this standard_conforming_strings thing hit, all of my scripts that run out of cron started pouring out warning messages which I initially could not figure out how to get rid of. IIRC, whatever version of Fedora I was running at the time had a version of PostgreSQL that generated these stupid warnings, and a version of DBD::Pg that hadn't yet been updated. It was thoroughly miserable. Yeah, I probably could have gotten around it by writing my own custom escaping function or downloading DBD::Pg off of CPAN and compiling it, but at the time I didn't even understand whether that would actually fix the problem. Plus, I'm not sure anyone here would be willing to advocate the way that the implicit casting stuff went down as a model for future changes of similar type. ....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 |