| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
| Date: | 2013-01-03 16:38:49 |
| Message-ID: | CAM-w4HO89ZvrVXw=az6mNmRxMtfqjEDDZWaPffFqiTduW4dUPQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 3, 2013 at 2:06 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I'd be alright with this also, tbh. Not preserving such information
> across pg_dump's wouldn't really be all *that* much of a loss.
I think it would be mandatory for pg_dump not to restore this info
actually. A fair amount of work has gone into pg_dump -s to ensure
that the output is identical for identical databases. OIDs were
removed and the sort order was changed to be deterministic for
example. Any "alter table set creation time 'xxx'" will defeat that
entirely.
When last I managed a production Postgres database I would use pg_dump
-s to regenerate a schema file that was checked into revision control.
And when I migrated changes live I would rerun pg_dump -s and diff
that against the checked in schema.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Samuel Vogel | 2013-01-03 16:48:26 | Print b-tree tuples |
| Previous Message | Magnus Hagander | 2013-01-03 16:32:19 | Re: pg_retainxlog for inclusion in 9.3? |