Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
