Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1qCOEU-0006CI-5S
	for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Jun 2023 17:36:34 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1qCOER-0003zI-9h
	for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Jun 2023 17:36:31 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1qCOER-0003z8-0H
	for pgsql-hackers@lists.postgresql.org; Thu, 22 Jun 2023 17:36:31 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1qCOEG-003etg-KK
	for pgsql-hackers@lists.postgresql.org; Thu, 22 Jun 2023 17:36:29 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 35MHaEjw4082751;
	Thu, 22 Jun 2023 13:36:14 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org>
cc: Tommy Pavlicek <tommypav122@gmail.com>,
 pgsql-hackers@lists.postgresql.org,
        Tomas Vondra <tomas.vondra@enterprisedb.com>
Subject: Re: [PATCH] Extend ALTER OPERATOR to support adding commutator,
 negator, hashes, and merges
In-reply-to: <87r0q3qvxd.fsf@wibble.ilmari.org>
References: 
 <CAEhP-W-vGVzf4udhR5M8Bdv88UYnPrhoSkj3ieR3QNrsGQoqdg@mail.gmail.com>
 <4077062.1687452468@sss.pgh.pa.us> <87r0q3qvxd.fsf@wibble.ilmari.org>
Comments: In-reply-to =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?=
 <ilmari@ilmari.org>
	message dated "Thu, 22 Jun 2023 17:54:54 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4082749.1687455374.1@sss.pgh.pa.us>
Date: Thu, 22 Jun 2023 13:36:14 -0400
Message-ID: <4082750.1687455374@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/4082750.1687455374%40sss.pgh.pa.us>
Precedence: bulk

=?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