2012/2/28 Shigeru Hanada <shigeru.han...@gmail.com>:
> (2012/02/27 12:35), Robert Haas wrote:
>> On Sat, Feb 25, 2012 at 3:56 PM, Thom Brown<t...@linux.com>  wrote:
>>>>> If there seems to be a consensus on removing system column from foreign
>>>>> tables, I'd like to work on this issue.  Attached is a halfway patch,
>>>>> and ISTM there is no problem so far.
>>>>
>>>>
>>>> I can say that at least PgAdmin doesn't use these columns.
>>>
>>> So we still have all of these columns for foreign tables.  I've tested
>>> Hanada-san's patch and it removes all of the system columns.  Could we
>>> consider applying it, or has a use-case for them since been
>>> discovered?
>>
>> Not to my knowledge, but Hanada-san described his patch as a "halfway
>> patch", implying that it wasn't done.
>
> Sorry for long absence.
>
> I've used the word "halfway" because I didn't have enough time to
> examine that patch at that time.  I tested the patch, and now I think
> it's OK to apply.  One concern is that there is no mention about
> unavailable system columns in any document.  ddl.sgml has main
> description of system columns, but it just says:
>
> <quote>
> Every table has several system columns that are implicitly defined by
> the system.
> </quote>
>
> Since this doesn't mention detailed type of relation, such as VIEW and
> COMPOSITE TYPE, IMO we can leave this paragraph as is.
>
> BTW, I still think that tableoid is useful if foreign tables can inherit
> other tables.  With such feature, tableoid of foreign table is necessary
> to determine actual source table.  Once we want to support that feature,
> IMO we should revive tableoid system column for foreign tables.

I'm not familiar with foreign table inheritance, or how it would work.
 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?

-- 
Thom

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to