Re: inherit support for foreign tables - Mailing list pgsql-hackers

Hello,

> >  BTW, why aren't you using the tlist passed to this function? I guess
> >> create_scan_plan() passes tlist after processing it, so that should be
> >> used rather than rel->reltargetlist.
> >>
> >
> > I think that that would be maybe OK, but I think that it would not be
> > efficient to use the list to compute attrs_used, because the tlist would
> > have more information than rel->reltargetlist in cases where the tlist is
> > build through build_physical_tlist().
> >
> >
> In that case, we can call build_relation_tlist() for foreign tables.

# is it build_base_rel_tilst() ?

It needs only one effective line added, which would be seemingly
far simple ingoring potential extra calculation for non-child
relations (I suppose getting rid of it needs a foreach on
rel->append_rel_list..) and too-longer physical tlist.  On the
other hand build_relation_tlist() and this patch seem to be in
the same order of computational complexity for the length of the
tlist.

I prefer to use build_base_rel_tlist() for the clarity of
code. But I don't know how high the chance to big physical tlist
and non-child relations become to be an annoyance. Is there any
suggestions?



By the way, I tried xmin and xmax for the file_fdw tables.

postgres=# select tableoid, xmin, xmax, * from passwd1;
tableoid | xmin |    xmax    |     uname     | pass |  uid  |  gid  | ..   16396 |  244 | 4294967295 | root          |
x   |     0 |     0 | root...  16396 |  252 | 4294967295 | bin           | x    |     1 |     1 | bin...  16396 |  284
|4294967295 | daemon        | x    |     2 |     2 | daemon...
 

The xmin and xmax apparently doesn't look sane. After some
investigation, I found that they came from the following place in
heap_form_tuple(), (call stach is show below)

| HeapTupleHeaderSetDatumLength(td, len);
| HeapTupleHeaderSetTypeId(td, tupleDescriptor->tdtypeid);
| HeapTupleHeaderSetTypMod(td, tupleDescriptor->tdtypmod);

HeapTupleHeader is a union of HeapTupleFields and
DatumTupleFields and these macors seem to treat it as the
latter. Then later this tuple seems to be read as the former so
xmin and xmax should have that values.

This seems to be a bug. But I have no idea how to deal with it
for now. I'll take more look into this.

The call stack onto the above heap_form_tuple is as follows.

#0  heap_form_tuple (tupleDescriptor=0x7fc46d2953a8, values=0x10dd1a0, isnull=0x10dd1f8 "") at heaptuple.c:731
#1  ExecCopySlotTuple (slot=0x10dd0e0) at execTuples.c:574
#2  ExecMaterializeSlot (slot=0x10dd0e0) at execTuples.c:760
#3  ForeignNext (node=0x10dc7b0) at nodeForeignscan.c:61
#4  ExecScanFetch (node=0x10dc7b0, accessMtd=0x66599c <ForeignNext>, recheckMtd=0x665a43 <ForeignRecheck>) at
execScan.c:82
#5  ExecScan (node=0x10dc7b0, accessMtd=0x66599c <ForeignNext>, recheckMtd=0x665a43 <ForeignRecheck>) at
execScan.c:167
#6  ExecForeignScan (node=0x10dc7b0) at nodeForeignscan.c:91
#7  ExecProcNode (node=0x10dc7b0) at execProcnode.c:442



regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center