From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: fill_extraUpdatedCols is done in completely the wrong place
Date: Fri, 08 May 2020 15:05:27 -0400
Message-ID: <10206.1588964727@sss.pgh.pa.us> (raw)
I happened to notice $subject while working on the release notes.
AFAICS, it is 100% inappropriate for the parser to compute the
set of generated columns affected by an UPDATE, because that set
could change before execution. It would be really easy to break
this for an UPDATE in a stored rule, for example.
I think that that processing should be done by the planner, instead.
I don't object too much to keeping the data in RTEs ... but there had
better be a bold annotation that the set is not valid till after
planning.
An alternative solution is to keep the set in some executor data structure
and compute it during executor startup; perhaps near to where the
expressions are prepared for execution, so as to save extra stringToNode
calls.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: fill_extraUpdatedCols is done in completely the wrong place
In-Reply-To: <10206.1588964727@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox