Re: preserving data after updates
От | Berend Tober |
---|---|
Тема | Re: preserving data after updates |
Дата | |
Msg-id | 428D0266.1040509@seaworthysys.com обсуждение исходный текст |
Ответ на | preserving data after updates (Scott Frankel <leknarf@pacbell.net>) |
Список | pgsql-general |
Greg Patnude wrote: > Yeah… this is where the inheritance model gets a little funky… What do > you have “SQL_INEHERITANCE” set to when you dump the database ? I’ve > never tested this so I don’t know if it makes a difference being on or > off when you dump a table…. You might try it and compare the two > versions of the DDL for your inherited tables… > I set SQL_INEHERITANCE to OFF because I have lots of existing queries in an application that do not include the "ONLY" option. I did try setting it back on the default ON, and the problem remained.. > Note: postgreSQL recommends leaving SQL_INHERITANCE at “ON” and using > the keyword “ONLY” > > I’ve seen that before… The problem is that pg_dump creates the > person_history table as a standalone table (look at the DDL) with the > keyword “INHERITS” – My gut feeling is that this is probably a bug in > pg_dump – I don’t think pg_dump really knows how to dump just the > additional fields specified in an inherited table so it dumps the > actual definition it finds in the system catalogs… > > If you poke around in pg_catalog, you’ll find that the catalog > definition is a combination of pointers to the parent table and any > additional fields, constraints, rules, etc you defined when you > created the inherited table. > > My work-around has been to drop and recreate the history tables using > the “original” SQL I used to create the inherited table in the first > place… >
В списке pgsql-general по дате отправления: