Tom Lane <t...@sss.pgh.pa.us> writes: > Tommy Pavlicek <tommypav...@gmail.com> writes: > >> Additionally, I wasn't sure whether it was preferred to fail or succeed on >> ALTERs that have no effect, such as adding hashes on an operator that >> already allows them or disabling hashes on one that does not. I chose to >> raise an error when this happens, on the thinking it was more explicit and >> made the code simpler, even though the end result would be what the user >> wanted. > > You could argue that both ways I guess. We definitely need to raise error > if the command tries to change an existing nondefault setting, since that > might break things as per previous discussion. But perhaps rejecting > an attempt to set the existing setting is overly nanny-ish. Personally > I think I'd lean to "don't throw an error if we don't have to", but I'm > not strongly set on that position. > > (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. > regards, tom lane - ilmari
