Re[2]: [PATCH] Optional OR REPLACE in CREATE OPERATOR statement

Поиск
Список
Период
Сортировка
От Svetlana Derevyanko
Тема Re[2]: [PATCH] Optional OR REPLACE in CREATE OPERATOR statement
Дата
Msg-id 1657108855.606587877@f406.i.mail.ru
обсуждение исходный текст
Ответ на Re: [PATCH] Optional OR REPLACE in CREATE OPERATOR statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re[2]: [PATCH] Optional OR REPLACE in CREATE OPERATOR statement  (Nikita Malakhov <hukutoc@gmail.com>)
Список pgsql-hackers
 
Вторник, 5 июля 2022, 18:29 +03:00 от Tom Lane <tgl@sss.pgh.pa.us>:
 
Svetlana Derevyanko <s.derevyanko@postgrespro.ru> writes:
> It seems useful to have [OR REPLACE] option in CREATE OPERATOR statement, as in CREATE FUNCTION. This option may be good for writing extension update scripts, to avoid errors with re-creating the same operator.

No, that's not acceptable. CREATE OR REPLACE should always produce
exactly the same final state of the object, but in this case we cannot
change the underlying function if the operator already exists.

(At least, not without writing a bunch of infrastructure to update
existing views/rules that might use the operator; which among other
things would create a lot of deadlock risks.)

regards, tom lane
Hello,
 
> CREATE OR REPLACE should always produce exactly the same final state of the object,
> but in this case we cannot change the underlying function if the operator already exists.
   
Do you mean that for existing operator CREATE OR REPLACE should be the same as DROP OPERATOR and CREATE OPERATOR,  with relevant re-creation of existing view/rules/..., using this operator? If yes, what exactly is wrong with  changing only RESTRICT and JOIN parameters (or is the problem in possible user`s confusion with attempts to change something more?). If no, could you, please, clarify what "final state" here means?
 
Also, if OR REPLACE is unacceptable, then what do you think about IF NOT EXISTS option?
 
Thanks,
 
--
Svetlana Derevyanko
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: pg15b2: large objects lost on upgrade
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg15b2: large objects lost on upgrade