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: Tom Lane on 3 Feb 2010 12:39 "Greg Sabino Mullane" <greg(a)turnstep.com> writes: > As one of the more vocal critics of the 8.3 implicit casting > incident, I say +1 on making the change. Unlike casting, it's > a simple GUC change to "fix", and now (9.0) is the time to > do it. Unfortunately, no: six months ago was the time to do it. 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. 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: Aidan Van Dyk on 3 Feb 2010 13:02 * Tom Lane <tgl(a)sss.pgh.pa.us> [100203 12:39]: > "Greg Sabino Mullane" <greg(a)turnstep.com> writes: > > As one of the more vocal critics of the 8.3 implicit casting > > incident, I say +1 on making the change. Unlike casting, it's > > a simple GUC change to "fix", and now (9.0) is the time to > > do it. > > Unfortunately, no: six months ago was the time to do it. > > 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. I'm not really worried about users using/testing PG from CVS or alphas - they are users following PG closely enough that the switch is easy for them to handle. *I* think beta1 is the when this *needs* to be done by. Sure, it would have been nicer if it was earlier, but beta1 is when "users" start actually using/testing (by "users" here, I mean ones who aren't closely following PG development, and changes). After beta1 comes out, it's absolutely a no-go, but if changing standard_conforming_strings is something the "community" wants to go towards, then I say do it now, before we're locked into another release and another year of it. a. -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
From: Robert Haas on 3 Feb 2010 13:20 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 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 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. ....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: Alvaro Herrera on 3 Feb 2010 13:36 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. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 3 Feb 2010 13:37
Robert Haas <robertmhaas(a)gmail.com> wrote: > What harm is being done by the status quo? What benefit do > we get out of changing the default? I really think that the biggest harm is that people trying to convert to PostgreSQL, or testing PostgreSQL with their applications, can get bad behavior from use of standard string literals. If they post to a list and we point out the setting, that'll probably be the end of the trouble -- and I have seen a few such posts. Interestingly, the frequency of such posts dropped off after 8.2 was released with the GUC to configure it, which suggests that people are often reading documentation before making the attempt or at least doing web searches about the problem and fixing it without a post to the community. I do think we might be well-served to have such issues as this and the "it's not a character string literal, it's a literal of UNKNOWN type" covered in a page which is prominent enough to be likely to be read by those considering migration or compatibility testing. I'm not sure exactly where that would be, unless it's a couple more FAQ entries -- but a "compatibility and migration" page might be worth creating, with a reasonably prominent link from the home page. -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 |