From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: fill_extraUpdatedCols is done in completely the wrong place |
Date: | 2020-05-18 14:54:06 |
Message-ID: | 989410e6-1da7-d763-e8cf-f4a3d999db94@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2020-05-18 15:02:34 | Re: factorial function/phase out postfix operators? |
Previous Message | Peter Eisentraut | 2020-05-18 14:42:18 | factorial function/phase out postfix operators? |