Re: [HACKERS] Column ADDing issues - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Column ADDing issues
Date
Msg-id Pine.LNX.4.21.0001262020480.416-100000@localhost.localdomain
Whole thread Raw
In response to Re: [HACKERS] Column ADDing issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Column ADDing issues
List pgsql-hackers
On 2000-01-25, Tom Lane mentioned:

> > Everything has its order and it's not like the inheritance as such is
> > broken.
> 
> Yes, a whole bunch of stuff is broken after this happens.  Go back and
> consult the archives --- or maybe Chris Bitmead will fill you in; he's
> got plenty of scars to show for this set of problems.  (All I recall
> offhand is that pg_dump and reload can fail to generate a working
> database.)  The bottom line is that it would be a lot nicer if column c
> had the same column position in both the parent table and the child
> table(s).

This should be fixed in pg_dump by infering something via the oids of the
pg_attribute entries. No need to mess up the backend for it.

Maybe pg_dump should optionally dump schemas in terms of insert into
pg_something commands rather than actual DDL. ;)

> 
> I suggest you be very cautious about messing with ALTER TABLE until you
> understand why inheritance makes it such a headache ;-)

I'm just trying to get the defaults and constraints working. If
inheritance stays broken the way it previously was, it's beyond my
powers. But I get the feeling that people rather not alter their tables
unless they have *perfect* alter table commands. I don't feel like arguing
with them, they'll just have to do without then.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: [HACKERS] Ars Digita and PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4