Re: Bug in CREATE OPERATOR

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug in CREATE OPERATOR
Дата
Msg-id 5711.977334718@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Bug in CREATE OPERATOR  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Список pgsql-hackers
"Christopher Kings-Lynne" <chriskl@familyhealth.com.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Replication toolkit added to repository
Следующее
От: Paul A Vixie
Дата:
Сообщение: day 2 results