Re: [PATCH] Opclass parameters - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Opclass parameters
Date
Msg-id 21380.1544115339@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Opclass parameters  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] Opclass parameters  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: slow queries over information schema.tables
Next
From: Robert Haas
Date:
Subject: Re: proposal: plpgsql pragma statement