Re: Proposed new create command, CREATE OPERATOR CLASS

On Wed, 24 Oct 2001, Tom Lane wrote:

> Bill Studenmund <wrstuden@netbsd.org> writes:
> > [ revised proposal for CREATE OPERATOR CLASS syntax ]
>
> I don't like the idea of writing a bunch of consecutive commas (and
> having to count them correctly) for cases where we're inserting
> noncontigous amopstrategy or amprocnum numbers.  Perhaps the syntax
> for the elements of the lists could be
>
>     [ integer ]  operator  [ ( argtype, argtype ) ] [ RECHECK ]
>
>     [ integer ]  funcname ( argtypes )
>
> where if the integer is given, it is the strategy/procnum for this
> entry, and if it's not given then it defaults to 1 for the first
> item and previous-entry's-number-plus-one for later items.

That would work.

> Or just require the integer all the time.  That seems a lot less
> mistake-prone, really.  Concision is not a virtue in the case of
> a command as specialized as this.  Is there really anything wrong with
>
> CREATE OPERATOR CLASS complex_abs_ops
>     DEFAULT FOR TYPE complex USING btree
>     WITH
>         1  ||<,
>         2  ||<=,
>         3  ||=,
>         4  ||>=,
>         5  ||>
>     AND
>         1  complex_abs_cmp(complex, complex);

Not really. Especially when there are ones which are 3, 6, 7, 8, 20
floating around. :-)

> (One could imagine adding system catalogs that give symbolic names
> to the strategy/procnum numbers for each access method, and then
> allowing names instead of integers in this command.  I'm not sure
> whether GiST has sufficiently well-defined strategy numbers to make that
> work, but even if not, I like this better than a positional approach to
> figuring out which operator is which.)

Something like that (having a catalog of what the different operators are
supposed to be) would be nice. Especially for the support procs, so that
CREATE OPERATOR CLASS could make sure you gave the right ones for each
number.

> > I decided to change that to an operator followed by "needs_recheck" to
> > indicate a recheck is needed. "needs_recheck" is not handled as a keyword,
> > but as an IDENT which is examined at parse time.
>
> Ugh.  Make it a keyword.  As long as it can be a TokenId there is no
> downside to doing so, and doing it that way eliminates interesting
> issues about case folding etc.  (Did you know that case folding rules
> are slightly different for keywords and identifiers?)

Ok. Will do. Yes, I know the case folding is different, though I'm not
100% sure how so. I assume it's something like for identifiers, acents &
such get folded to unaccented characters?

> I still like RECHECK better than NEEDS_RECHECK, but that's a minor
> quibble.

RECHECK is one word. I'll go with it.

Take care,

Bill