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
