Re: [HACKERS] Column ADDing issues
От
Peter Eisentraut
Тема
Re: [HACKERS] Column ADDing issues
Дата
Msg-id
Pine.LNX.4.21.0001262020480.416-100000@localhost.localdomain
Ответ на
Re: [HACKERS] Column ADDing issues (Tom Lane)
Список
Дерево обсуждения
Column ADDing issues Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Column ADDing issues Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Column ADDing issues Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] Column ADDing issues Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Column ADDing issues "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Re: [HACKERS] Column ADDing issues Bruce Momjian <pgman@candle.pha.pa.us>
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 по дате отправления
От: Tom Lane
Дата: