Skip site navigation (1) Skip section navigation (2)

Re: PG 9.0 and standard_conforming_strings

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: (view raw, whole thread or download thread mbox)
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.


Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,                                   work like a slave.

In response to

pgsql-hackers by date

Next:From: Joe ConwayDate: 2010-02-03 18:08:16
Subject: Re: use of dblink_build_sql_insert() induces a server crash
Previous:From: Tim BunceDate: 2010-02-03 17:56:53
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group