Robert Haas <robertmh...@gmail.com> writes: > On Tue, Feb 28, 2012 at 7:00 AM, Shigeru Hanada > <shigeru.han...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers