Re: [PATCH] Opclass parameters

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Opclass parameters
Дата
Msg-id 21380.1544115339@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Opclass parameters  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PATCH] Opclass parameters  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Dec 5, 2018 at 6:58 PM Nikita Glukhov <n.gluhov@postgrespro.ru> wrote:
>> "opclass (options)" looks the most natural to me. But we still need some
>> keyword before the parentheses when the opclass is not specified since we
>> can't distinguish "func_name (func_params)" and "col_name (opclass_options)"
>> in grammar.

> Are you sure?  What's the SQL syntax where there is actually a problem
> here?  CREATE INDEX requires parentheses around a non-trivial
> expression.

Well, the reason we have to require parens around nontrivial expressions
is mostly lack of forethought about making the syntax non-ambiguous :-(

> How about just OPTIONS (options) ?

That would require making OPTIONS a fully reserved word, I think,
else it's ambiguous with an opclass name.

How about saying that you must give an opclass name if you want to
specify options, ie the syntax is

    [ opclass_name [ ( options... ) ] ]

I'm not necessarily wedded to that, but it seems worth throwing
out the idea.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: slow queries over information schema.tables
Следующее
От: Robert Haas
Дата:
Сообщение: Re: proposal: plpgsql pragma statement