| From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
|---|---|
| To: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] UPDATE on subclass |
| Date: | 2000-02-08 04:12:11 |
| Message-ID: | 389F979B.51A62C09@nimrod.itg.telecom.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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?
>
> ************
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Bitmead | 2000-02-08 04:24:14 | Is this it? |
| Previous Message | Chris Bitmead | 2000-02-08 03:47:35 | UPDATE on subclass |