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 1sYGdd-00A88m-Gj for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Jul 2024 03:01:29 +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 1sYGda-00EOUl-Vh for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Jul 2024 03:01:26 +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 1sYGda-00EOUd-NJ for pgsql-bugs@lists.postgresql.org; Mon, 29 Jul 2024 03:01:26 +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 1sYGdT-001zva-Mc for pgsql-bugs@lists.postgresql.org; Mon, 29 Jul 2024 03:01:25 +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 46T31G3d2460424; Sun, 28 Jul 2024 23:01:16 -0400 From: Tom Lane To: Peter Smith cc: 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> Comments: In-reply-to Peter Smith message dated "Mon, 29 Jul 2024 12:45:19 +1000" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2460422.1722222076.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sun, 28 Jul 2024 23:01:16 -0400 Message-ID: <2460423.1722222076@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Smith writes: > On Mon, Jul 29, 2024 at 12:23 PM Tom Lane wrote: >> Agreed on that, but shouldn't this patch also be removing some code >> from the ALTER ... SET path? Or is that part of the cleanup you >> handwaved about? > I was thinking that if publication_translate_columns() is modified to > return the BMS, which it is building internally anyway, then we avoid > processing the column list 2x. Then the above ALTER SET code can be > removed. Is that the same code ("shouldn't this patch also be removing > some code") you were referring to? If publication_translate_columns is already building that exact same BMS, then yeah we're on the same page. I hadn't checked the code to see. If you'd have to add code to publication_translate_columns, then maybe it'd be better to make AlterPublicationTables build the BMS from what publication_translate_columns returns presently. regards, tom lane