On Wed, Dec 26, 2012 at 11:13 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers