Bernd Helmle writes:
--On 8. September 2010 09:00:33 +0100 Dean Rasheed
wrote:
Here's an updated version with improved formatting and a few minor
wording changes to the triggers chapter.
This version doesn't apply clean anymore due to some rejects in
plainmain.c. Corrected version attached.
Applied with revisions. A couple of points worth remarking:

* I took out this change in planmain.c:

+ /*
+ * If the query target is a VIEW, it won't be in the jointree, but we
+ * need a dummy RelOptInfo node for it. This need not have any stats in
+ * it because it always just goes at the top of the plan tree.
+ */
+ if (parse->resultRelation &&
+ root->simple_rel_array[parse->resultRelation] == NULL)
+ build_simple_rel(root, parse->resultRelation, RELOPT_OTHER_MEMBER_REL);

AFAICT that's just dead code: the only reason to build such a rel would
be if there were Vars referencing it in the main part of the plan tree.
But there aren't. Perhaps this was left over from some early iteration
of the patch before you had the Var numbering done right? Do you know
of any cases where it's still needed?

* I also took out the changes in preprocess_targetlist() that tried to
prevent equivalent wholerow vars from getting entered in the targetlist.
This would not work as intended since the executor has specific
expectations for the names of those junk TLEs; it'd fail if it ever
actually tried to do an EvalPlanQual recheck that needed those TLEs.
Now I believe that an EPQ recheck is impossible so far as the update or
delete itself is concerned, when the target is a view. So if you were
really concerned about the extra vars, the non-kluge route to a solution
would be to avoid generating RowMarks in the first place. You'd have to
think a bit about the possibility of SELECT FOR UPDATE in sub-selects
though; the query as a whole might need some rowmarks even if the top
level Modify node doesn't. On the whole I couldn't get excited about
this issue, so I just left it alone.

regards, tom lane

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 23 of 24 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 15, '10 at 5:38p
activeOct 11, '10 at 7:54a
posts24
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase