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 ) id 1m19sY-0002zw-QD for pgsql-bugs@arkaria.postgresql.org; Wed, 07 Jul 2021 15:54:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m19sX-0007Us-Dx for pgsql-bugs@arkaria.postgresql.org; Wed, 07 Jul 2021 15:54:25 +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 ) id 1m19sX-0007Se-73 for pgsql-bugs@lists.postgresql.org; Wed, 07 Jul 2021 15:54:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m19sU-0004Ov-Jw for pgsql-bugs@lists.postgresql.org; Wed, 07 Jul 2021 15:54:24 +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 167FsJOw1838680; Wed, 7 Jul 2021 11:54:20 -0400 From: Tom Lane To: Peter Eisentraut cc: Etsuro Fujita , dacherny@gmail.com, PostgreSQL mailing lists Subject: Re: BUG #16631: postgres_fdw tries to insert into generated columns In-reply-to: <8a61d9c4-b614-e2dc-6bcc-bfc17db4d2f9@enterprisedb.com> References: <16631-e929fe9db0ffc7cf@postgresql.org> <8a61d9c4-b614-e2dc-6bcc-bfc17db4d2f9@enterprisedb.com> Comments: In-reply-to Peter Eisentraut message dated "Wed, 07 Jul 2021 10:44:58 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1838678.1625673259.1@sss.pgh.pa.us> Date: Wed, 07 Jul 2021 11:54:19 -0400 Message-ID: <1838679.1625673259@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > On 07.07.21 09:20, Etsuro Fujita wrote: >> * Modified nodeModifyTable.c and copyfrom.c so that they don't compute >> generated columns for FDWs anymore. > I don't agree with that change. What is the point of declaring a > generated column on a foreign table if you ignore it? Then you might as > well prohibit declaring such columns in the first place. Maybe what we need here is some documentation clarifying exactly what the point of a generated column on a foreign table actually *is*. When would you do it, and what relationship if any has it got to the generation status of the underlying remote column? regards, tom lane