(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?
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
