Re: fill_extraUpdatedCols is done in completely the wrong place

On 2020-05-08 21:05, Tom Lane wrote:
> 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.

Do you have a specific situation in mind?  How would a rule change the 
set of columns updated by a query?  Something involving CTEs?  Having a 
test case would be good.

> 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.

Yeah, really only the executor ended up needing this, so perhaps it 
should be handled in the executor.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services