From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_migrator versus inherited columns |
Date: | 2009-07-02 00:25:56 |
Message-ID: | 8479.1246494356@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-07-02 00:41:29 | Re: single bit integer (TINYINT) revisited for 8.5 |
Previous Message | Josh Berkus | 2009-07-02 00:21:33 | First CommitFest: July 15th |