Re: Schema as versioning strategy

From: Jonathan Vanasco <jvanasco(at)2xlp(dot)com>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Owen Hartnett <owen(at)clipboardinc(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Schema as versioning strategy
Date: 2007-04-25 22:45:21
Message-ID: F471D19C-BE79-40D3-94A5-8A87B6CE8997@2xlp.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


On Apr 25, 2007, at 2:05 PM, Richard Huxton wrote:

> Owen Hartnett wrote:
>> I want to "freeze" a snapshot of the database every year (think of
>> end of year tax records). However, I want this frozen version
>> (and all the previous frozen versions) available to the database
>> user as read-only. My thinking is to copy the entire public
>> schema (which is where all the current data lives) into a new
>> schema, named 2007 (2008, etc.)
>
> Sounds perfectly reasonable. You could either do it as a series of:
> CREATE TABLE archive2007.foo AS SELECT * FROM public.foo;
> or do a pg_dump of schema "public", tweak the file to change the
> schema names and restore it.

the create table method won't copy the constraints + fkeys .

i think you're best off with a pgdump

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jorge Godoy 2007-04-25 22:50:11 Re: Audit-trail engine: getting the application's layer user_id
Previous Message Listmail 2007-04-25 22:13:13 Re: Vacuum-full very slow

Browse pgsql-hackers by date

  From Date Subject
Next Message Reece Hart 2007-04-25 23:00:59 Re: Schema as versioning strategy
Previous Message Listmail 2007-04-25 22:13:13 Re: Vacuum-full very slow