2012年2月28日12:00 Shigeru Hanada <shigeru.hanada@gmail.com>:
> (2012/02/28 18:08), Thom Brown wrote:
>> If that's something that will likely be introduced in future, then
>> surely we'd want to keep the tableoid column rather than removing it
>> then re-introducing it later?
>
> As background knowledge, currently (9.1 and 9.2dev) foreign tables have
> all system columns, but they return meaningless values except tableoid.
> For instance, a foreign table pgbench_branches with 3 rows will return
> results like below ("bid" in the rightmost is user column):
>
> postgres=# select ctid, xmin, cmin, xmax, cmax, tableoid,
> postgres-# bid from pgbench_branches;
> ctid | xmin | cmin | xmax | cmax | tableoid | bid
> ----------------+------+------+------+------+----------+-----
> (4294967295,0) | 0 | 0 | 0 | 0 | 16400 | 2
> (4294967295,0) | 0 | 0 | 0 | 0 | 16400 | 3
> (4294967295,0) | 0 | 0 | 0 | 0 | 16400 | 1
> (3 rows)
>
> In this example, 16400 is correct oid of pg_class record for relation
> pgbench_branches.
>
> I don't have any idea to use system columns other than tableoid of
> foreign tables, because it seems difficult to define common meaning for
> various FDWs. One possible idea about ctid column is using it for
> virtual tuple id (location information of remote data) for update
> support, if FDW can pack location information into ItemPointerData area.
>
> We have three options:
>
> a) remove all system columns (posted patch)
> b) remove system columns other than tableoid
> c) leave all system columns as is (current 9.2dev)
>
> Incidentally, views, which is very similar object type to foreign
> tables, have no system columns.
>
> Thoughts?
>
Which is the expected behavior in case of a foreign table
is constructed as a child table of a particular regular table?
In this case, children foreign tables don't have columns
that exist on the parent table?
(Although it is no matter when a regular table is a child of
a foreign table...)
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>