database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-23 14:01:44 +03:00
Code Activity

Update comments for rewriteTargetListIU().

Browse Source 
This function's behavior for UPDATE on a trigger-updatable view was
justified by analogy to what preptlist.c used to do for UPDATE on
regular tables.  Since preptlist.c hasn't done that since 86dc90056,
that argument is no longer sensible, let alone convincing.  I think
we do still need it to act that way, so update the comment to explain
why.
This commit is contained in:
Tom Lane
2021-04-25 18:02:03 -04:00
parent 59773da2b1
commit 08a9869665
1 changed files with 4 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/rewrite/rewriteHandler.c
View File

@ -681,12 +681,10 @@ adjustJoinTreeList(Query *parsetree, bool removert, int rt_index)
* *
* 2. For an UPDATE on a trigger-updatable view, add tlist entries for any * 2. For an UPDATE on a trigger-updatable view, add tlist entries for any
* unassigned-to attributes, assigning them their old values. These will * unassigned-to attributes, assigning them their old values. These will
* later get expanded to the output values of the view. (This is equivalent * later get expanded to the output values of the view. This is only needed
* to what the planner's expand_targetlist() will do for UPDATE on a regular * for trigger-updatable views, for which the view remains the result relation
* table, but it's more convenient to do it here while we still have easy * of the query; without it, we would not have a complete "new tuple" to pass
* access to the view's original RT index.) This is only necessary for * to triggers. For auto-updatable views we must not do this, since it might
* trigger-updatable views, for which the view remains the result relation of
* the query. For auto-updatable views we must not do this, since it might
* add assignments to non-updatable view columns. For rule-updatable views it * add assignments to non-updatable view columns. For rule-updatable views it
* is unnecessary extra work, since the query will be rewritten with a * is unnecessary extra work, since the query will be rewritten with a
* different result relation which will be processed when we recurse via * different result relation which will be processed when we recurse via