On Tue, 23 Oct 2001, Bill Studenmund wrote:
> Here's the syntax I'd like to propose:
>
> CREATE OPERATOR CLASS <name> [DEFAULT] FOR TYPE <typename> USING <access
> method> WITH <list of operators> AND <list of support functions>
Hmmm.. Teach me to read the docs. :-) There's no way to set opckeytype. So
hwo about:
CREATE OPERATOR CLASS <name> [DEFAULT] FOR TYPE <typename> [AS <stored
type>] USING <access method> WITH <list of operators> AND <list of support
functions>
With AS <stored type> present, the opckeytype column gets set to that type
name's oid.
> New keywords are "CLASS" (SQL99 reserved word) and "REPEATABLE" (SQL99
> non-reserved word, see below for usage).
>
> <name> is the class's name, and <typename> is the type to be indexed.
> <access method> is the assosciated access method from pg_am (btree, rtree,
> hash, gist).
>
> The presence of [DEFAULT] indicates that this operator class shold be made
> the default operator class for the type.
>
> <list of operators> is a comma-delimited list of operator specs. An
> operator spec is either an operator or an operator followed by the keyword
> "REPEATABLE". The presence of "REPEATABLE" indicates that amopreqcheck
> should be set to true for this operator. Each item in this list will
> generate an entry in pg_amop.
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.
> <list of support functions> is a comma-seperated list of functions used to
> assist the index method. Each item in this list will generate an item in
> pg_amproc.
>
> I agree that I think it is rare that anything will set "REPEATABLE", but
> the point of this effort is to keep folks from mucking around with the
> system tables manually, so we should support making any reasonable entry
> in pg_amop.
Take care,
Bill