Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 28, 2012 at 7:00 AM, Shigeru Hanada
> <shigeru.hanada@gmail.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
feature.
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
working.
regards, tom lane
