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 1kWt2R-0003lS-2O for pgsql-bugs@arkaria.postgresql.org; Mon, 26 Oct 2020 03:19:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kWt2P-0005Av-Rv for pgsql-bugs@arkaria.postgresql.org; Mon, 26 Oct 2020 03:19:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWt2P-0005An-M5 for pgsql-bugs@lists.postgresql.org; Mon, 26 Oct 2020 03:19:13 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWt2N-0004BD-7F for pgsql-bugs@lists.postgresql.org; Mon, 26 Oct 2020 03:19:13 +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 09Q3J4US638929; Sun, 25 Oct 2020 23:19:04 -0400 From: Tom Lane To: Amit Langote cc: fedor_erastov@mail.ru, PostgreSQL mailing lists , Andres Freund , Andrew Dunstan Subject: Re: BUG #16644: null value for defaults in OLD variable for trigger In-reply-to: References: <16644-5da7ef98a7ac4545@postgresql.org> <802555.1601432494@sss.pgh.pa.us> <207142.1603468329@sss.pgh.pa.us> <568704.1603648770@sss.pgh.pa.us> <623211.1603659215@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Mon, 26 Oct 2020 12:11:23 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <638927.1603682344.1@sss.pgh.pa.us> Date: Sun, 25 Oct 2020 23:19:04 -0400 Message-ID: <638928.1603682344@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > On Mon, Oct 26, 2020 at 5:53 AM Tom Lane wrote: >> Moreover, it's more correct, even disregarding the problem >> at hand, because the tlist isn't a perfectly accurate depiction of >> the relation rowtype: ExecCleanTypeFromTL will not derive the correct >> info for dropped columns. > Hmm, I don't understand. Isn't it the planner's job to make the > targetlist correctly account for dropped columns; what > expand_targetlist() does? Yes, there are columns in the tlist to match them, but ExecCleanTypeFromTL cannot mark those columns as "attisdropped". The column data type likely won't be right either. The latter shouldn't matter, if the column is being filled with a null ... but I'm a bit surprised that we've gotten away this long with not being honest about attisdropped. regards, tom lane