Re: Proposal: Store "timestamptz" of database creation on "pg_database"

On Wed, Dec 26, 2012 at 11:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This has been debated, and rejected, before.
>
> To mention just one problem, are we going to add nonstandard,
> non-backwards-compatible syntax to every single kind of CREATE to allow
> pg_dump to preserve the creation dates? Another interesting question is
> whether we should likewise track the last ALTER time, or perhaps whether
> a sufficiently major ALTER redefinition should update the creation time.

Well, IMHO, there is no need for any syntax change at all. CREATE
TABLE and CREATE DATABASE should just record the creation time
somewhere, and that's all. If you dump-and-reload, the creation time
changes. Deal with it, or hack your catalogs if you really care that
much.

I find the suggestion of using event triggers for this to miss the
point almost completely. At least in my case, the time when you
really wish you had some timestamps is when you get dropped into a
customer environment and need to do forensics. The customer will not
have installed the convenient package of event triggers at database
bootstrap time. Their environment will likely be poorly configured
and completely undocumented; that's why you're doing forensics, isn't
it?

I know this has been discussed and rejected before, but I find that
rejection to be wrong-headed. I have repeatedly been asked, with
levels of exasperation ranging from mild to homicidal, why we don't
have this feature, and I have no good answer. If it were somehow
difficult to record this or likely to produce a lot of overhead, that
would be one thing. But it isn't. It's probably a hundred-line
patch, and AFAICS the overhead would be miniscule.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company