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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: 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: 2012-12-28 02:14:58
Message-ID: 20121228021457.GF16126@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri,

* Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)fr) wrote:
> Here's a complete test case that works with my current branch, with a
> tricky test while at it, of course:

Apparently I've managed to miss the tricky case..?

Sure, dropping tables, schemas, etc, would have an impact on the values.
Dropping a table and then recreating it would be akin to deleteing a row
and then inserting a new one- the create value would be set to the time
of the new table being created and information about the dropped table
would be lost.

I'm not thinking of this as audit tracking where every action is logged.

I agree that what I was suggesting would be possible to implement with
event triggers, but I see that as a rather advanced feature that most
users aren't going to understand or implement. At the same time, those
more novice users are likely to be looking for this kind of information-
being told "oh, well, you *could* have been collecting it all along if
you knew about event triggers" isn't a particularly satisfying answer.

That's my 2c on it.

I agree that having the example in the docs would be nice- examples are
always good things to include.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-28 06:09:41 Re: fix bgworkers in EXEC_BACKEND
Previous Message anarazel@anarazel.de 2012-12-28 00:28:49 Re: fix bgworkers in EXEC_BACKEND