PostgreSQL Source Code interpretation (10)-insert data # 9 (ProcessQuery)
Mt_ plans [I]-> plan; aerm = ExecBuildAuxRowMark (erm, subplan- > targetlist); mtstate- > mt_ Arowmarks [I] = lappend (mtstate- > mt_arowmarks [I], aerm);}} / * select first subplan * / mtstate- > mt_whichplan = 0; subplan = (Plan *) linitial (node- > plans) EvalPlanQualSetPlan (& mtstate- > mt_epqstate, subplan, mtstate- > mt_arowmarks [0]); / * Initialize the junk filter (s) if needed. INSERT queries need a filter * if there are any junk attrs in the tlist. UPDATE and DELETE always * need a filter, since there's always at least one junk attribute present *-no need to look first. Typically, this will be a 'ctid' or *' wholerow' attribute, but in the case of a foreign data wrapper it * might be a set of junk attributes sufficient to identify the remote * row. * If there are multiple result relations, each one needs its own junk * filter. Note multiple rels are only possible for UPDATE/DELETE, so we * can't be fooled by some needing a filter and some not. * This section of code is also a convenient place to verify that the * output of an INSERT or UPDATE matches the target table (s) * / {bool junk_filter_needed = false; switch (operation) {case CMD_INSERT: foreach (l, subplan- > targetlist) {TargetEntry * tle = (TargetEntry *) lfirst (l) If (tle- > resjunk) {junk_filter_needed = true; break;}} break Case CMD_UPDATE: case CMD_DELETE: junk_filter_needed = true; break; default: elog (ERROR, "unknown operation"); break;} if (junk_filter_needed) {resultRelInfo = mtstate- > resultRelInfo For (I = 0; I)
< nplans; i++) { JunkFilter *j; subplan = mtstate->