From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
Date: | 2012-12-27 12:08:56 |
Message-ID: | 20121227120856.GQ12354@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> >This information could be extremely useful for forensics, debugging, ETL
> >processes (many of which create tables as part of their processes), etc.
>
> I'd say "moderately useful" at best. Quite a number of things could
> make the creation dates misleading or not distinctive (think
> partition replacement, restore from pg_dump, replicas, etc.).
> ALTER dates would be more useful, but as Tom points out, would need
> the user-configurability which can only be delivered by something
> like event triggers.
To be honest, I really just don't find this to be *that* difficult and
an intuitive set of rules which are well documented feels like it'd
cover 99% of the cases. pg_dump would preserve the times (though it
could be optional), replicas should as well, etc. We haven't even
started talking about the 'hard' part, which would be a 'modification'
type of field..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2012-12-27 12:43:15 | Re: buffer assertion tripping under repeat pgbench load |
Previous Message | Heikki Linnakangas | 2012-12-27 10:06:12 | Re: pg_basebackup from cascading standby after timeline switch |