Re: Precedence of standard comparison operators

Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Can you, or can anyone, show a plausible example of something
>> that would work under the old rules and work under the new rules
>> but with a different meaning? I have to admit that I'm having
>> some difficulty imagining exactly when that happens. Tom's
>> examples upthread were not things that seemed all that likely.

> I think very few will see any problems. At Wisconsin Courts we had
> millions of lines of code when we moved to PostgreSQL and saw one
> or two queries which had problems with this. The example I gave
> earlier on this thread was:

> | test=# select 'f'::boolean = 'f'::boolean >= 'f'::boolean;
> | ?column?
> | ----------
> | f
> | (1 row)

> Now, that was a simple case for purposes of illustration, but
> imagine that the first two literals are column names in a complex
> query and it becomes slightly less ridiculous. Imagine they are
> being passed in to some plpgsql function which accepts different
> types, and the statement is run through EXECUTE and it may be
> somewhat reasonable.

Note that that example now *fails*, because = and => now belong
to the same precedence level which is %nonassoc:

regression=# select 'f'::boolean = 'f'::boolean >= 'f'::boolean;
ERROR: syntax error at or near ">="
LINE 1: select 'f'::boolean = 'f'::boolean >= 'f'::boolean;
^

(It'd be nice if it gave a more specific error message than just
"syntax error", but I'm not sure if there's any practical way to
persuade bison to do something different than that.)

I think that the set of practical examples that produce a different
answer without outright failing (either due to %nonassoc or due to
lack of any matching operator) is really going to be darn small.

> Either way it is like leaving the barn door open so that horses are
> capable of running out. We have an alarm that lets you know when
> something is going through the barn door; the question is whether
> to default that alarm on or off.

If we believe that the set of affected apps really is small, then
it seems like there should not be much downside to having the
warning on by default: by hypothesis, few people will ever see it
at all. OTOH, there is some small run-time cost to having it on...

The %nonassoc syntax error problem is likely to be a bigger problem
for user-friendliness than anything else about this patch, IMO.
Now that we're committed to this course, I will do some research
and see if that behavior can be improved at all.

regards, tom lane