Skip site navigation (1) Skip section navigation (2)

Re: Proposed new create command, CREATE OPERATOR CLASS

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Bill Studenmund <wrstuden(at)netbsd(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposed new create command, CREATE OPERATOR CLASS
Date: 2002-02-22 19:43:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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:
> 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:
> 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                        |
  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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-02-22 20:01:19
Subject: Re: Storage Location Patch Proposal for V7.3
Previous:From: Bruce MomjianDate: 2002-02-22 19:11:35
Subject: Re: Package support for Postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group