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

  1. Documentation corrections for opclass parameters

  2. Implement operator class parameters