Re: Precedence of standard comparison operators - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Precedence of standard comparison operators
Date
Msg-id CA+U5nM+G8AFt=Vy5syPnpaf=px1wpZ3GaGY1=phJQticRk71ew@mail.gmail.com
Whole thread Raw
In response to Re: Precedence of standard comparison operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: contrib/fuzzystrmatch/dmetaphone.c license
Next
From: Stephen Frost
Date:
Subject: Re: collations in shared catalogs?