| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Svetlana Derevyanko <s(dot)derevyanko(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Optional OR REPLACE in CREATE OPERATOR statement |
| Date: | 2022-07-05 15:29:28 |
| Message-ID: | 1917173.1657034968@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
=?UTF-8?B?U3ZldGxhbmEgRGVyZXZ5YW5rbw==?= <s(dot)derevyanko(at)postgrespro(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2022-07-05 16:03:18 | Re: Handle infinite recursion in logical replication setup |
| Previous Message | Jelte Fennema | 2022-07-05 15:23:04 | Re: [EXTERNAL] Re: Support load balancing in libpq |