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  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список 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 по дате отправления:

Предыдущее
От: 张连壮
Дата:
Сообщение: pg_stat_database update stats_reset only by pg_stat_reset
Следующее
От: Kuntal Ghosh
Дата:
Сообщение: Re: PANIC :Call AbortTransaction when transaction id is no normal