Re: Precedence of standard comparison operators

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Precedence of standard comparison operators
Дата
Msg-id CA+U5nM+G8AFt=Vy5syPnpaf=px1wpZ3GaGY1=phJQticRk71ew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Precedence of standard comparison operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Precedence of standard comparison operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Precedence of standard comparison operators  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 20 February 2015 at 20:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Well, assuming that we're satisfied with just having a way to warn
> when the behavior changed (and not, in particular, a switch that can
> select old or new behavior)

I'm in favour of your proposed improvements, but I'm having a problem
thinking about random application breakage that would result.

Having a warn_if_screwed parameter that we disable by default won't
help much because if you are affected you can't change that situation.
There are too many applications to test all of them and not all
applications can be edited, even if they were tested.

I think the way to do this is to have a pluggable parser, so users can
choose 1) old parser, 2) new, better parser, 3) any other parser they
fancy that they maintain to ensure application compatibility. We've
got a pluggable executor and optimizer, so why not a parser too?
Implementing that in the same way we have done for executor and
optimizer is a 1 day patch, so easily achievable for 9.5.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, RemoteDBA, Training &
Services



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: contrib/fuzzystrmatch/dmetaphone.c license
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: collations in shared catalogs?