Re: Precedence of standard comparison operators

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Precedence of standard comparison operators
Date: 2015-02-25 22:15:01
Message-ID: CA+U5nM+G8AFt=Vy5syPnpaf=px1wpZ3GaGY1=phJQticRk71ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20 February 2015 at 20:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-02-25 22:47:04 Re: collations in shared catalogs?
Previous Message Andrew Dunstan 2015-02-25 22:10:10 Re: contrib/fuzzystrmatch/dmetaphone.c license