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

Re: FDW system columns

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

> I vote against (c).  I'm not sure which of (a) or (b) is better.
> We've talked about allowing foreign tables to inherit from regular
> tables and visca versa, and certainly, in that situation, tableoid
> would be useful.

I think it is a mistake to imagine that tableoid is only useful in
inheritance contexts.  As one counterexample, pg_dump selects tableoid
from quite a lot of system catalogs, just as a convenient and uniform
way of remembering each object's type (of course, the fact that it needs
to match them up against pg_depend entries has something to do with
that).  More generally, if we exclude tableoid from foreign tables,
that just introduces an arbitrary behavioral difference between foreign
and regular tables, thus complicating any code that has use for the

So I believe that (a) is a pretty bad choice.  I would hold still for
(b) but I am not convinced that the case has been made for that either.
I think it would be wise to avoid introducing behavioral churn until
after we have designed and implemented update capabilities for foreign
tables.  If we end up putting back ctid to support that, we'll look
pretty silly.

In short, (c) looks like the most reasonable choice for now, with the
expectation of revisiting the question after we have foreign update

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Thom BrownDate: 2012-02-28 15:14:29
Subject: Re: Command Triggers, patch v11
Previous:From: Kevin GrittnerDate: 2012-02-28 15:09:01
Subject: Re: Command Triggers, patch v11

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