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.94.2) (envelope-from ) id 1sYR0t-00BKoI-QT for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Jul 2024 14:06:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sYR0r-000EU0-92 for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Jul 2024 14:06:09 +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.94.2) (envelope-from ) id 1sYR0r-000ETs-0Y for pgsql-bugs@lists.postgresql.org; Mon, 29 Jul 2024 14:06:09 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYR0n-0024wM-FW for pgsql-bugs@lists.postgresql.org; Mon, 29 Jul 2024 14:06:08 +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 46TE62Qc2580483; Mon, 29 Jul 2024 10:06:02 -0400 From: Tom Lane To: David Rowley cc: Peter Smith , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18558: ALTER PUBLICATION fails with unhelpful error on attempt to use system column In-reply-to: References: <18558-411bc81b03592125@postgresql.org> <2455740.1722219823@sss.pgh.pa.us> <2460423.1722222076@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Mon, 29 Jul 2024 18:14:08 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2580481.1722261962.1@sss.pgh.pa.us> Date: Mon, 29 Jul 2024 10:06:02 -0400 Message-ID: <2580482.1722261962@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On the whole, I think the API of these functions could be improved as > it's made the fix for this bug more convoluted than it needs to be. +1 > I'm on the fence if this should be done as part of this bug fix. The > reason I think it might is that you're changing > publication_translate_columns() to be non-static, and if the above API > change gets done later, that's then changing the API of an existing > external function. The reason against is that it's more risky to do in > the back branches as it's changing more code. What do others think? If we are going to export a formerly-static function, we should make its API as clean as we can. I doubt that that adds meaningful risk, and it avoids people possibly getting bit by cross-branch differences. > Is it worth adding an ALTER PUBLICATION test with a duplicate column too? Probably, just to prove that the non-duplicative representation does what we want. regards, tom lane