WIP: Enhanced ALTER OPERATOR - Mailing list pgsql-hackers
From | Uriy Zhuravlev |
---|---|
Subject | WIP: Enhanced ALTER OPERATOR |
Date | |
Msg-id | 3348985.V7xMLFDaJO@dinodell Whole thread Raw |
Responses |
Re: WIP: Enhanced ALTER OPERATOR
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: WIP: Enhanced ALTER OPERATOR (Uriy Zhuravlev <u.zhuravlev@postgrespro.ru>) Re: WIP: Enhanced ALTER OPERATOR (Uriy Zhuravlev <u.zhuravlev@postgrespro.ru>) Re: WIP: Enhanced ALTER OPERATOR (Uriy Zhuravlev <u.zhuravlev@postgrespro.ru>) |
List | pgsql-hackers |
Hello Hackers. I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR, NEGATOR, RESTRICT and JOIN. This patch is based on master. It is small patch with regression tests. Why do it? The operator has four important parameters that can be set only during the creation. These are: commutator (oprcom), negator (oprnegate), restrict (oprrest), join (oprjoin). For example, you created operator with RESTRICT = contsel . After a while you began to actively use your new operator. Then you develop a new function for RESTRICT (my_restrict_func). To change the RESTRICT operator you have to create a new database and to migrate there because operator is used and you can't DROP OPERATOR and CREATE OPERATOR again. The fact that it is extremely difficult sometimes almost think it is clear to all. It is interesting that the change in the parameters of the operator takes place periodically for the built-in operators (when changing major version), but it is impossible for users defined operators. Real life example is intarray ( http://www.postgresql.org/message-id/CAPpHfdssY+qEPDCOvxx-b4LP3ybR+qS04M6-ARgGKNFk3FrFow@mail.gmail.com). Also using ALTER OPERATOR for self-linkage more logical than make operator shells. Simple syntax example: ALTER OPERATOR === (boolean, boolean) SET COMMUTATOR =; ALTER OPERATOR === (boolean, boolean) SET NEGATOR =; ALTER OPERATOR === (boolean, boolean) SET RESTRICT example_func; ALTER OPERATOR === (boolean, boolean) SET JOIN example_func; ALTER OPERATOR === (boolean, boolean) SET COMMUTATOR NONE; ALTER OPERATOR === (boolean, boolean) SET NEGATOR NONE; ALTER OPERATOR === (boolean, boolean) SET RESTRICT NONE; ALTER OPERATOR === (boolean, boolean) SET JOIN NONE; It seems to me a syntax similar to the classic ALTER will be better than what was used in the CREATE OPERATOR. In this patch I am: 1. renamed OperatorUpd to ShellOperatorUpd. It more right name. 2. created AlterOperatorStmt struct for parsing command. 3. created ExecAlterOperatorStmt function for check user rights and select parameter for edit. 4. recreated OperatorUpd for update params of operator in catalog. 5. And other small fix for extend parser. In AlterOperatorStmt confuses me to use const char for cmd_name. In addition, I clean only the catalog cache but judging by how works shell operators, nothing more is needed. Thanks! -- Uriy Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Attachment
pgsql-hackers by date: