Re: PG 9.0 and standard_conforming_strings

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: PG 9.0 and standard_conforming_strings
Дата
Msg-id 20100203180237.GL23327@oak.highrise.ca
обсуждение исходный текст
Ответ на Re: PG 9.0 and standard_conforming_strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [100203 12:39]:
> "Greg Sabino Mullane" <greg@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@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tim Bunce
Дата:
Сообщение: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Следующее
От: Joe Conway
Дата:
Сообщение: Re: use of dblink_build_sql_insert() induces a server crash