Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
От | Tom Lane |
---|---|
Тема | Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges |
Дата | |
Msg-id | 4082750.1687455374@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>) |
Ответы |
Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
|
Список | pgsql-hackers |
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> (Don't we have existing precedents that apply here? I can't offhand >> think of any existing ALTER commands that would reject no-op requests, >> but maybe that's not a direct precedent.) > Since it only supports adding these operations if they don't already > exist, should it not be ALTER OPERATOR ADD <thing>, not SET <thing>? > That makes it natural to add an IF NOT EXISTS clause, like ALTER TABLE > ADD COLUMN has, to make it a no-op instead of an error. Hmm, maybe. But it feels like choosing syntax and semantics based on what might be only a temporary implementation restriction. We certainly don't handle any other property-setting commands that way. Admittedly, "can't change an existing setting" is likely to be pretty permanent in this case, just because I don't see a use-case for it that'd justify the work involved. (My wife recently gave me a coffee cup that says "Nothing is as permanent as a temporary fix.") But still, if someone did show up and do that work, we'd regret this choice of syntax because it'd then be uselessly unlike every other ALTER command. regards, tom lane
В списке pgsql-hackers по дате отправления: