Re: [PATCH] Opclass parameters
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>,
Nikolay Shaplov <dhyan@nataraj.su>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Oleg Bartunov <obartunov@gmail.com>
Date: 2018-12-06T16:55:39Z
Lists: 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
Commits
-
Documentation corrections for opclass parameters
- 3f1802e1fdb7 13.0 landed
-
Implement operator class parameters
- 911e70207703 13.0 landed