From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com> |
Subject: | Re: [PATCH] Opclass parameters |
Date: | 2018-12-06 16:55:39 |
Message-ID: | 21380.1544115339@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Dec 5, 2018 at 6:58 PM Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-12-06 16:57:00 | Re: proposal: plpgsql pragma statement |
Previous Message | Robert Haas | 2018-12-06 16:50:48 | Re: slow queries over information schema.tables |