Bill Studenmund <[EMAIL PROTECTED]> 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.
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);
(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.)
> 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?)
I still like RECHECK better than NEEDS_RECHECK, but that's a minor
quibble.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
