| 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: | Whole Thread | Raw Message | 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 |