WIP: Enhanced ALTER OPERATOR

From: Uriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>
To: pgsql-hackers(at)postgresql(dot)org
Subject: WIP: Enhanced ALTER OPERATOR
Date: 2015-05-18 14:12:22
Message-ID: 3348985.V7xMLFDaJO@dinodell
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
extend_alter_operator_v1.patch text/x-patch 29.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-18 14:21:10 Re: WIP: Enhanced ALTER OPERATOR
Previous Message Tom Lane 2015-05-18 14:12:04 Re: upper planner path-ification