Skip site navigation (1) Skip section navigation (2)

Re: FDW system columns

From: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FDW system columns
Date: 2012-02-28 12:00:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
(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

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.


Shigeru Hanada

In response to


pgsql-hackers by date

Next:From: Thom BrownDate: 2012-02-28 13:32:09
Subject: Re: Command Triggers, patch v11
Previous:From: Thom BrownDate: 2012-02-28 11:43:54
Subject: Re: Command Triggers, patch v11

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group