Re: SQL-spec incompatibilities in similar_escape() and related stuff
От | Andrew Gierth |
---|---|
Тема | Re: SQL-spec incompatibilities in similar_escape() and related stuff |
Дата | |
Msg-id | 87v9yeg69c.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: SQL-spec incompatibilities in similar_escape() and related stuff (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: SQL-spec incompatibilities in similar_escape() and related stuff
|
Список | pgsql-hackers |
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes: Tom> I am, frankly, inclined to ignore this as a bad idea. We do have Tom> SIMILAR and ESCAPE as keywords already, but they're Tom> type_func_name_keyword and unreserved_keyword respectively. To Tom> support this syntax, I'm pretty sure we'd have to make them both Tom> fully reserved. Andrew> I only did a quick trial but it doesn't seem to require Andrew> reserving them more strictly - just adding the obvious Andrew> productions to the grammar doesn't introduce any conflicts. Digging deeper, that's because both SIMILAR and ESCAPE have been assigned precedence. Ambiguities that exist include: ... COLNAME ! SIMILAR ( ... which could be COLNAME postfix-op SIMILAR a_expr, or COLNAME infix-op function-call. Postfix operators strike again... we really should kill those off. The ESCAPE part could in theory be ambiguous if the SIMILAR expression ends in a ... SIMILAR TO xxx operator, since then we wouldn't know whether to attach the ESCAPE to that or keep it as part of the function syntax. But I think this is probably a non-issue. More significant is that ... COLNAME ! ESCAPE ... again has postfix- vs. infix-operator ambiguities. -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: