Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>> ^
>
>>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>>> ^
>
>>> I think the former error location is better.
>
>> So do I.
>
> Uh, why? It looks like it's complaining about the constant 123,
> not about the operator.
I wrote that before I saw your post, which left me ambivalent. My
thinking was that it seems clearest to me when it points to the token
at which things become untenable. At this point there it is still
possible for the statement to be completed with a valid query:
SELECT 'aa' SIMILAR TO
At this point it is not:
SELECT 'aa' SIMILAR TO 123
If you had something like '123' instead of 123, it would be OK, so I'd
be good with it complaining about the constant 123.
SELECT 'aa' SIMILAR TO '123';
?column?
----------
f
(1 row)
But if we normally point to the operator when it isn't in the set
allowed with the given operands, then consistency trumps the above.
I yield the point.
-Kevin