From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Column ADDing issues |
Date: | 2000-01-27 17:41:45 |
Message-ID: | Pine.LNX.4.21.0001262020480.416-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-01-27 17:41:55 | Re: [HACKERS] Column ADDing issues |
Previous Message | Bruce Momjian | 2000-01-27 16:37:24 | Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 |