Re: Proposed new create command, CREATE OPERATOR CLASS - Mailing list pgsql-hackers

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@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

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