Re: Bug in CREATE OPERATOR

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in CREATE OPERATOR
Date: 2000-12-20 17:51:58
Message-ID: 5711.977334718@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> [ "CREATE OPERATOR testbit" is accepted ]

Not only that, but it looks like you can create aggregate functions and
types that have operator-like names :-(. Someone was way too eager to
save a production or two, I think:

DefineStmt: CREATE def_type def_name definition
{
...
}
;

def_type: OPERATOR { $$ = OPERATOR; }
| TYPE_P { $$ = TYPE_P; }
| AGGREGATE { $$ = AGGREGATE; }
;

def_name: PROCEDURE { $$ = "procedure"; }
| JOIN { $$ = "join"; }
| all_Op { $$ = $1; }
| ColId { $$ = $1; }
;

Seems to me that this should be simplified down to

CREATE OPERATOR all_Op ...

CREATE TYPE ColId ...

CREATE AGGREGATE ColId ...

Any objections? Has anyone got an idea why PROCEDURE and JOIN are
special-cased here? PROCEDURE, at least, could be promoted from
ColLabel to ColId were it not offered as an alternative to ColId here.

> Now we have a big problem, as the DROP OPERATOR command cannot delete the
> illegally named operator.

Just remove it by DELETEing the row from pg_operator.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-12-20 18:00:02 Re: Another OPERATOR bug??
Previous Message Tom Lane 2000-12-20 17:42:26 Re: 7.1 snapshot on i386 BSD MAJOR failure