Re: preserving data after updates - Mailing list pgsql-general

From Berend Tober
Subject Re: preserving data after updates
Date
Msg-id 428D0266.1040509@seaworthysys.com
Whole thread Raw
In response to preserving data after updates  (Scott Frankel <leknarf@pacbell.net>)
List 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 by date:

Previous
From: Berend Tober
Date:
Subject: Re: Preserving data after updates
Next
From: "Dann Corbit"
Date:
Subject: Re: numeric precision when raising one numeric to another.