From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PG 9.0 and standard_conforming_strings |
Date: | 2010-02-03 18:02:38 |
Message-ID: | 20100203180237.GL23327@oak.highrise.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [100203 12:39]:
> "Greg Sabino Mullane" <greg(at)turnstep(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2010-02-03 18:08:16 | Re: use of dblink_build_sql_insert() induces a server crash |
Previous Message | Tim Bunce | 2010-02-03 17:56:53 | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |