Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vspYh-0038df-2b for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Feb 2026 21:58:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vspYg-000bKs-2l for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Feb 2026 21:58:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vspXY-000XgJ-1w for pgsql-hackers@lists.postgresql.org; Wed, 18 Feb 2026 21:57:00 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vspXV-000000002Y4-2DnP for pgsql-hackers@lists.postgresql.org; Wed, 18 Feb 2026 21:57:00 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 618BE578CC2 for ; Wed, 18 Feb 2026 22:56:57 +0100 (CET) Received: from s981.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 3E565579705; Wed, 18 Feb 2026 22:56:57 +0100 (CET) Received: from s473.loopia.se (unknown [172.22.191.6]) by s981.loopia.se (Postfix) with ESMTP id 3BF9322B1703; Wed, 18 Feb 2026 22:56:57 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s473.loopia.se (amavisd-new); dkim=pass (2048-bit key) header.d=proxel.se Received: from s979.loopia.se ([172.22.191.6]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with LMTP id yGEob4R6_BM8; Wed, 18 Feb 2026 22:56:56 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: andreas@proxel.se X-Loopia-Originating-IP: 147.28.75.140 Received: from [192.168.0.121] (customer-147-28-75-140.stosn.net [147.28.75.140]) (Authenticated sender: andreas@proxel.se) by s979.loopia.se (Postfix) with ESMTPSA id B769B10BC4B6; Wed, 18 Feb 2026 22:56:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proxel.se; s=loopiadkim1707418970; t=1771451816; bh=Vpqq8jcIVoP/6EV4TxCFQbvvrvb8i2qk0uG1tgGtqYs=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=UFLRqFQ5LSYNLWfdzAUqcrtD1VRrM6c8KhrZSuiR5ajdU+mAiJnB13T8eogm4+Wjl f20o/UQbvxnSWOqAwaVR6m+82gQDQVaqOVXYlj02w2HTc3bMlxmvk01iqp+/oMcIHC 2Gm4NXsfFG4H25WbFBXWVms7IGbuAUf2klJ4Curs0U/RVIDh1WpjaTygceV7HqrIqK NlTwvmvD4S9decCXuvcWaU6gQIpQL7Qu9CMWWa+4SzdR8cn+wwYSSLA/o8OKKqsVZw VapqPtncUQtVYpTXvmFEvUbPVY8H1VhCxlNcR6RxDkf9VzJfK7CN0UiMzuneAH2TgL YASyNC77+2SZA== Message-ID: <8f291697-8389-4913-9a4c-5c5cee717fca@proxel.se> Date: Wed, 18 Feb 2026 22:56:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: updates for handling optional argument in system functions To: Mark Wong , Chao Li Cc: pgsql-hackers@lists.postgresql.org References: <0604F7D7-EABE-47CA-A58A-231CBD0DA659@gmail.com> From: Andreas Karlsson Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 1/30/26 1:15 AM, Mark Wong wrote: >> Thanks for the patch. After reviewing it, I have mixed feelings. From one side, it removes some redundant code, which is good. In the other side, I doubt if we should delete proc entries from pg_proc.c? Say, there is a view that uses a proc to be deleted, the proc OID is stored with the view, then after an upgrade, the view would be broken. From this perspective, should we retain the old proc entries and only point them to the new functions? > > I don't have a solution for the case of a view storing the OID, but Álvaro > Herrera suggested to me to at least try preventing those OIDs from being > reused. > > I've attached a v3 patch set that introduces src/include/catalog/pg_retired.dat > to store previously used OIDs and procedure names that the scripts unused_oids > and renumber_oids.pl can consume to prevent the reuse of retired OIDs. > > Maybe that can also be used towards finding that particular solution... I am not sure what can be done, breaking people's databases on pg_upgrade is certainly not nice and detecting that function oid has been used anywhere in a database sounds painful, especially since there are no references to system oids in pg_depend, right? That said this patch should be updated to use the new support for default values in BKI files.[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=759b03b24ce96f0ba6d734b570d1a6f4a0fb1177 Andreas