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
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 |
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 |