Thread: Patch to add CREATE OPERATOR CLASS
I've attached a patch to add the CREATE OPERATOR CLASS we talked about on -hackers. I've also attached a new _int.sql.in file showing off how to use the command. Thoughts? Take care, Bill ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Attachment
Oh, I see it now. Sorry.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Bill Studenmund wrote:
> I've attached a patch to add the CREATE OPERATOR CLASS we talked about on
> -hackers.
>
> I've also attached a new _int.sql.in file showing off how to use the
> command.
>
> Thoughts?
>
> Take care,
>
> Bill
Content-Description: New _int.sql.in for contrib/intarray
[ Attachment, skipping... ]
Content-Description: Patch
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
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, Pennsylvania 19026
Bill, this patch was rejected. Can you resubmit to hackers for discussion? Thanks. --------------------------------------------------------------------------- Bill Studenmund wrote: > I've attached a patch to add the CREATE OPERATOR CLASS we talked about on > -hackers. > > I've also attached a new _int.sql.in file showing off how to use the > command. > > Thoughts? > > Take care, > > Bill Content-Description: New _int.sql.in for contrib/intarray [ Attachment, skipping... ] Content-Description: Patch [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- 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, Pennsylvania 19026
On Sun, 24 Feb 2002, Bruce Momjian wrote: > > Bill, this patch was rejected. Can you resubmit to hackers for > discussion? Thanks. This is the second one? Why was it rejected? The first one was rejected, but the second was (as far as I could tell) exactly what Tom had wanted and what had been discussed at the time on -hackers (and was cleaner than the first)... Take care, Bill
Bill Studenmund wrote: > On Sun, 24 Feb 2002, Bruce Momjian wrote: > > > > > Bill, this patch was rejected. Can you resubmit to hackers for > > discussion? Thanks. > > This is the second one? Why was it rejected? The first one was rejected, > but the second was (as far as I could tell) exactly what Tom had wanted > and what had been discussed at the time on -hackers (and was cleaner than > the first)... Sorry, I wish I knew. Would you resubmit to hackers/patches list? I think we have lost some idea of the patch over time. -- 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, Pennsylvania 19026
Bill Studenmund <wrstuden@netbsd.org> writes:
> This is the second one? Why was it rejected?
As far as I could tell, the patch Bruce had on his to-apply list was the
first version. Please update your latest patch to current CVS (if it
needs any changes) and resubmit ...
regards, tom lane
Tom Lane wrote: > Bill Studenmund <wrstuden@netbsd.org> writes: > > This is the second one? Why was it rejected? > > As far as I could tell, the patch Bruce had on his to-apply list was the > first version. Please update your latest patch to current CVS (if it > needs any changes) and resubmit ... Found new version --- bounced it over to patches. -- 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, Pennsylvania 19026
Bill Studenmund writes:
> I've attached a patch to add the CREATE OPERATOR CLASS we talked about on
> -hackers.
I'm having a few issues with the syntax. Basically, what you have is
CREATE OPERATOR CLASS name FOR TYPE type AS ... USING ... WITH ... AND ...
How about choosing these key words so that they actually declare what the
... stands for. It would also nice if these could be allowed in a more
flexible order.
For instance,
CREATE OPERATOR CLASS name FOR TYPE type
{ STORAGE name
| ACCESS METHOD name
| FUNCTION num name(x, y, z)
| OPERATOR num name
} [, ...]
or
CREATE OPERATOR CLASS name FOR TYPE type
{
STORAGE name
| ACCESS METHOD name } [, ...]
| FUNCTION (
num name(x, y, z),
...
)
| OPERATOR (
num name,
...
)
}
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm having a few issues with the syntax. Basically, what you have is
> CREATE OPERATOR CLASS name FOR TYPE type AS ... USING ... WITH ... AND ...
> How about choosing these key words so that they actually declare what the
> ... stands for. It would also nice if these could be allowed in a more
> flexible order.
Good point. I'm not that excited about varying the order of clauses,
but certainly "AND" is not a helpful indication of which clause means
what.
The data type and access method are required identification info, so
I don't see a lot of value in a syntax that makes them look optional,
much less one that allows them to occur multiple times. How about
CREATE OPERATOR CLASS name [ DEFAULT ] FOR TYPE type USING accessmethod
{ FUNCTION num name(parms)
| OPERATOR num name [ ( type, type ) ] [ RECHECK ]
| STORAGE typename
} [, ...]
We could argue whether DEFAULT should be one of the flexibly-ordered
clauses rather than having the special position shown here. This way
seems more naturally readable to me, but I'm not dead set on it.
regards, tom lane
Tom Lane wrote:
>
> Peter Eisentraut <peter_e@gmx.net> writes:
> > I'm having a few issues with the syntax. Basically, what you have is
> > CREATE OPERATOR CLASS name FOR TYPE type AS ... USING ... WITH ... AND ...
>
> > How about choosing these key words so that they actually declare what the
> > ... stands for. It would also nice if these could be allowed in a more
> > flexible order.
>
> Good point. I'm not that excited about varying the order of clauses,
> but certainly "AND" is not a helpful indication of which clause means
> what.
>
> The data type and access method are required identification info, so
> I don't see a lot of value in a syntax that makes them look optional,
> much less one that allows them to occur multiple times. How about
>
> CREATE OPERATOR CLASS name [ DEFAULT ] FOR TYPE type USING accessmethod
> { FUNCTION num name(parms)
> | OPERATOR num name [ ( type, type ) ] [ RECHECK ]
> | STORAGE typename
> } [, ...]
>
> We could argue whether DEFAULT should be one of the flexibly-ordered
> clauses rather than having the special position shown here. This way
> seems more naturally readable to me, but I'm not dead set on it.
>
Everytime we allow a key word to appear in more than one place we
multiply
the number of states in the parser by some factor. Try doing it and
looking at y.output before and after. It also makes it harder to
maintain
the parser and to avoid conflicts when trying to add new commands.
Maybe that is why the SQL standard has required fixed positions for
these
kind of things.
I like Tom's proposed syntax, but I believe we should add an "AS" before
the part that is inside braces.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9