Re: SQL-spec incompatibilities in similar_escape() and related stuff - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: SQL-spec incompatibilities in similar_escape() and related stuff
Date
Msg-id 87k1eufem8.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: SQL-spec incompatibilities in similar_escape() and related stuff  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: SQL-spec incompatibilities in similar_escape() and related stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
 Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
 Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
 Andrew> as part of the function syntax. But I think this is probably a
 Andrew> non-issue. More significant is that ... COLNAME ! ESCAPE ...
 Andrew> again has postfix- vs. infix-operator ambiguities.

And this ambiguity shows up already in other contexts:

select 'foo' similar to 'f' || escape escape escape from (values ('oo')) v(escape);
psql: ERROR:  syntax error at or near "escape"
LINE 1: select 'foo' similar to 'f' || escape escape escape from (va...

select 'foo' similar to 'f' || escape escape from (values ('oo')) v(escape);
psql: ERROR:  operator does not exist: unknown ||
LINE 1: select 'foo' similar to 'f' || escape escape from (values ('...

I guess this happens because ESCAPE has precedence below POSTFIXOP, so
the ('f' ||) gets reduced in preference to shifting in the first ESCAPE
token.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Unlogged tables cleanup
Next
From: Justin Pryzby
Date:
Subject: Re: pg12 release notes