| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: result relation used anymore? |
| Date: | 2003-02-28 20:17:19 |
| Message-ID: | 6033.1046463439@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu> writes:
> While learning how to read query trees, I have been puzzled by the
> assertion in the manual that the :resultRelations of an INSERT holds
> `the table (or view!) where the changes take effect,' because in all
> of the INSERTs I have generated the resultRelation in fact appears
> empty,
You seem to be confusing resultRelation with resultRelations. The
documentation is speaking of the former. Of the latter, parsenodes.h
says
/*
* If the resultRelation turns out to be the parent of an inheritance
* tree, the planner will add all the child tables to the rtable and
* store a list of the rtindexes of all the result relations here.
* This is done at plan time, not parse time, since we don't want to
* commit to the exact set of child tables at parse time. This field
* ought to go in some sort of TopPlan plan node, not in the Query.
*/
List *resultRelations; /* integer list of RT indexes, or NIL */
Note in particular that this only gets set when the target is an
inheritance tree --- which, by definition, it never is for INSERT.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-02-28 20:40:54 | Re: Still a bug in the VACUUM ??? !!! |
| Previous Message | Tom Lane | 2003-02-28 19:51:49 | Re: Brain dump: btree collapsing |