Re: ADD/DROP INHERITS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ADD/DROP INHERITS
Date
Msg-id 1115.1149799629@sss.pgh.pa.us
Whole thread Raw
In response to Re: ADD/DROP INHERITS  (Greg Stark <gsstark@mit.edu>)
Responses Re: ADD/DROP INHERITS  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> So?  They'll get re-merged with the parent column during CREATE TABLE
>> anyway.

> But merged columns that are defined locally still appear in the position they
> were defined locally. Not with the other inherited columns.

Really?

regression=# create table p (p1 int, p2 int, p3 int);
CREATE TABLE
regression=# create table c (c1 int, c2 int) inherits (p);
CREATE TABLE
regression=# create table gc (gc1 int, p2 int, c1 int, gc2 int) inherits (c);
NOTICE:  merging column "p2" with inherited definition
NOTICE:  merging column "c1" with inherited definition
CREATE TABLE
regression=# \d gc     Table "public.gc"Column |  Type   | Modifiers
--------+---------+-----------p1     | integer |p2     | integer |p3     | integer |c1     | integer |c2     | integer
|gc1   | integer |gc2    | integer |
 
Inherits: c

regression=#

> Basically I think if you're doing multiple inheritance and start using
> add/drop inherits your column order is going to turn into chop suey quickly.

Very possibly, but that doesn't mean that we shouldn't take any concern
for avoiding unnecessary changes.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: ADD/DROP INHERITS
Next
From: Hannu Krosing
Date:
Subject: Re: ADD/DROP constraints