Thread: UPDATE on subclass
Been doing more tracing... The problem with UPDATE on inheritance hierarchies is that when it gets down into ExecSeqScan, the value of... node->scanstate->css_currentScanDesc->rs_rd->rd_id is not equal to the value of... node->plan.state->es_result_relation_info->ri_RelationDesc->rd_id On the first scan, the former is equal to the relation for the base class and the latter is equal to the relation for the subclass. Any thoughts anyone?
Hmm. In exec_append_initialize_next nth(whichplan, rtable) refers to the subclass and ... nth(whichplan, appendstate->as_result_relation_info_list); refers to the baseclass. Is there something that is constructing one of these structures in reverse order? Chris Bitmead wrote: > > Been doing more tracing... > > The problem with UPDATE on inheritance hierarchies is that when it gets > down into ExecSeqScan, the value of... > > node->scanstate->css_currentScanDesc->rs_rd->rd_id > > is not equal to the value of... > > node->plan.state->es_result_relation_info->ri_RelationDesc->rd_id > > On the first scan, the former is equal to the relation for the base > class > and the latter is equal to the relation for the subclass. > > Any thoughts anyone? > > ************
In ExecInitAppend it has a loop... foreach(rtentryP, rtable) { resultList = lcons(rri, resultList);}appendstate->as_result_relation_info_list = resultList; If I'm not mistaken this will generate the as_result_relation_info_list in the reverse order to the rtentry list, which is wrong... right?
Chris Bitmead wrote: > > In ExecInitAppend it has a loop... > > foreach(rtentryP, rtable) > { > > resultList = lcons(rri, resultList); > } > > appendstate->as_result_relation_info_list = resultList; This seems to be the problem. I'm going to change the above line to... appendstate->as_result_relation_info_list = lreverse(resultList); After I do this, UPDATE and DELETE start working for me on subclasses. I'll prepare a full patch for inclusion in 7.1 (Unless you want it for 7.0 :-).
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes: > In ExecInitAppend it has a loop... > foreach(rtentryP, rtable) > { > resultList = lcons(rri, resultList); > } > appendstate->as_result_relation_info_list = resultList; > If I'm not mistaken this will generate the as_result_relation_info_list > in the reverse order to the rtentry list, Check ... > which is wrong... right? Maybe. Is there code elsewhere that assumes these lists are ordered alike? You could change the lcons call to "lappend(resultList, rri)" if you just want to try the experiment. regards, tom lane