Re: preserving data after updates

From: Berend Tober <btober(at)seaworthysys(dot)com>
To: gpatnude(at)hotmail(dot)com
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: preserving data after updates
Date: 2005-05-19 21:17:26
Message-ID: 428D0266.1040509@seaworthysys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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…
>

Browse pgsql-general by date

  From Date Subject
Next Message Dann Corbit 2005-05-19 21:20:28 Re: numeric precision when raising one numeric to another.
Previous Message Berend Tober 2005-05-19 21:14:44 Re: Preserving data after updates