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 по дате отправления: