Re: pg_migrator versus inherited columns

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_migrator versus inherited columns
Дата
Msg-id 8479.1246494356@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_migrator versus inherited columns  (Greg Stark <gsstark@mit.edu>)
Ответы Re: pg_migrator versus inherited columns  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Comments?

> Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch.

Hmm, 8.3 doesn't seem to recognize the syntax:

regression=# alter table c add inherit p;
ERROR:  type "p" does not exist
LINE 1: alter table c add inherit p;                                 ^

> This will result in all the columns being marked attislocal. Ie, if
> they're dropped from the parent they won't be dropped automatically
> from the children any longer.

Good point.  We could have pg_dump fix that up, I suppose.  On the other
hand, I'm not entirely sure that the current dump methodology guarantees
to preserve attislocal correctly anyway.

> Frankly I never really liked attislocal -- it seems to me the user
> knows when he's dropping the column whether he wants it dropped from
> the children and should be able to explicitly request it to cascade or
> not.

The original discussions about attislocal/attinhcount came up with some
cases that seemed to make it necessary, but I've long forgotten the
details.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: First CommitFest: July 15th
Следующее
От: Greg Stark
Дата:
Сообщение: Re: single bit integer (TINYINT) revisited for 8.5