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
