Re: Proposed new create command, CREATE OPERATOR CLASS
От | Tom Lane |
---|---|
Тема | Re: Proposed new create command, CREATE OPERATOR CLASS |
Дата | |
Msg-id | 1391.1003975891@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposed new create command, CREATE OPERATOR CLASS (Bill Studenmund <wrstuden@netbsd.org>) |
Ответы |
Re: Proposed new create command, CREATE OPERATOR CLASS
|
Список | pgsql-hackers |
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. 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_opsDEFAULT FOR TYPE complex USING btreeWITH 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
В списке pgsql-hackers по дате отправления: