Re: [HACKERS] UPDATE on subclass - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: [HACKERS] UPDATE on subclass
Date
Msg-id 389F979B.51A62C09@nimrod.itg.telecom.com.au
Whole thread Raw
In response to UPDATE on subclass  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
List pgsql-hackers
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?
> 
> ************


pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: UPDATE on subclass
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] ExecInitAppend