Re: Precedence of standard comparison operators

Simon Riggs <simon@2ndQuadrant.com> writes:
> 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 find this argument to be unhelpful, because it could be made in exactly
the same words against any non-backwards-compatible change whatsoever.
Nonetheless, we do make non-backwards-compatible changes all the time.

> 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.

I don't find that particularly attractive either.  It seems quite unlikely
to me that anyone would actually use such a hook; replacing the whole
parser would be essentially unmaintainable.  Nobody uses the hooks you
mention to replace the whole planner or whole executor --- there are
wrappers out there, which is a different thing altogether.  But you could
not undo the issue at hand here without at the very least a whole new
copy of gram.y, which would need to be updated constantly if you wanted
it to keep working across more than one release.
        regards, tom lane