(2012/02/27 12:35), Robert Haas wrote:
> On Sat, Feb 25, 2012 at 3:56 PM, Thom Brown<thom(at)linux(dot)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
> 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:
Every table has several system columns that are implicitly defined by
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.
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2012-02-28 09:08:25|
|Subject: Re: incorrect handling of the timeout in pg_receivexlog|
|Previous:||From: Fujii Masao||Date: 2012-02-28 08:22:39|
|Subject: Re: pg_basebackup -x stream from the standby gets stuck|