Re: Proposed new create command, CREATE OPERATOR CLASS

Bill, do you have a newer version of this patch for application to 7.3?

---------------------------------------------------------------------------

Bill Studenmund wrote:
> I'd like to propose a new command, CREATE OPERATOR CLASS. Its purpose is
> to create a named operator class, so that you can create new types of
> index ops. Also, its inclusion would remove the section of the
> documentation where we tell people how to manually manipulate the system
> tables.
>
> Since schema support is going to change some of the details of the system
> tables in important ways, I think it's better to move away from manual
> updates.
>
> The command is basically an instrumentation of the documentation on how to
> add new operator classes.
>
> 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>
>
> 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.
>
> <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.
>
> Here's an example based on the programmer's guide. We've created the type
> "complex", and have comparison functions complex_abs_lt, complex_abs_le,
> complex_abs_eq, complex_abs_gt, complex_abs_ge. Then let us have created
> operators "||<", "||<=", "||=", "||>", "||>=" based on them. We also have
> the complex_abs_cmp helper function. To create the operator class, the
> command would be:
>
> CREATE OPERATOR CLASS complex_abs_ops DEFAULT FOR TYPE complex USING
> btree with ||<, ||<=, ||=, ||>=, ||> and complex_abs_cmp;
>
> Among other things, complex_abs_ops would be the default operator class
> for the complex type after this command.
>
>
> An example using REPEATABLE would be:
>
> CREATE OPERATOR CLASS complex_abs_ops DEFAULT FOR TYPE complex USING btree
> with ||< REPEATABLE, ||<=, ||=, ||>=, ||> REPEATABLE and complex_abs_cmp;
>
> Note: I don't think the above command will create a correct operator
> class, it just shows how to add REPEATABLE.
>
> The alternative to "REPEATABLE" would be something like
> "hit_needs_recheck" after the operator. Suggestions?
>
> Thoughts?
>
> Take care,
>
> Bill
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026