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
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 |