Re: Patch to add CREATE OPERATOR CLASS

Tom Lane wrote:
>
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > I'm having a few issues with the syntax. Basically, what you have is
> > CREATE OPERATOR CLASS name FOR TYPE type AS ... USING ... WITH ... AND ...
>
> > How about choosing these key words so that they actually declare what the
> > ... stands for. It would also nice if these could be allowed in a more
> > flexible order.
>
> Good point. I'm not that excited about varying the order of clauses,
> but certainly "AND" is not a helpful indication of which clause means
> what.
>
> The data type and access method are required identification info, so
> I don't see a lot of value in a syntax that makes them look optional,
> much less one that allows them to occur multiple times. How about
>
> CREATE OPERATOR CLASS name [ DEFAULT ] FOR TYPE type USING accessmethod
> { FUNCTION num name(parms)
> | OPERATOR num name [ ( type, type ) ] [ RECHECK ]
> | STORAGE typename
> } [, ...]
>
> We could argue whether DEFAULT should be one of the flexibly-ordered
> clauses rather than having the special position shown here. This way
> seems more naturally readable to me, but I'm not dead set on it.
>

Everytime we allow a key word to appear in more than one place we
multiply
the number of states in the parser by some factor. Try doing it and
looking at y.output before and after. It also makes it harder to
maintain
the parser and to avoid conflicts when trying to add new commands.
Maybe that is why the SQL standard has required fixed positions for
these
kind of things.

I like Tom's proposed syntax, but I believe we should add an "AS" before
the part that is inside braces.

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9