> As for what I want from the community, I would like other users > and dba's to weigh in on this request and it's usefulness.
When I was a DBA on a team responsible for hundreds of geographically distributed databases, initially using products with this feature and then moving to PostgreSQL, I occasionally found this feature to be a minor convenience when it was present. We kept the DDL for recreating everything under source control, and each new release contained the DDL to move from one state to the next, so such a column didn't give us anything we couldn't get by consulting the "official" DDL. But, as an example of where it could save a few minutes, if someone had been allowed to run ad hoc reports or data cleanup on a database it was a quick way to look for stray tables they may have generated to keep intermediate results or exceptions, so we could follow up on disposition of those tables.
It would take a lot of such incidents to add up to enough time to add this as a proper feature, which is probably why nobody with resources to devote to adding features has prioritized it to the point of developing a proposed patch. That and the fact that there is no guarantee that the community as a whole would feel that the feature "carried its own weight" in terms of benefit / maintenance cost, so it might not make it in anyway.
Adrian, To answer your questions: "The first time an object was ever created?" Yes, AFAIK, objects in pg_class can only be "created" once, so relcreatedat would be the timestamp it is initially created. Otherwise, if an object is dropped and subsequently re-created, then by definition the relcreatedat must again populated.
"The time it was created in a new database during a dump-restore/pg_upgrade/replication?" Yes for new database, but no for upgrade/replication as by definition, the objects would already exist..
Second thing:
"pg_class does not track all the objects in a database, so what other system catalogs should be included. With the same questions as above." I am only concerned with the objects in pg_class as id'd by relkind. IE: tables, indexes, sequences, etc.
Kevin,
Thank you for your additional feedback. adhoc user temp tables is just one case.
There is also the situation of tables with limitited use. EG: history_yyyymm, in which case it would facilitate dropping of tables that are no longer needed after x amount of time.
--
Melvin Davidson I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.