Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created - Mailing list pgsql-general

From Kevin Grittner
Subject Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created
Date
Msg-id CACjxUsOvJSb9pEoR+LWtG0yGD1y69kC0OKBr7amLWzTt3-cnNA@mail.gmail.com
Whole thread Raw
In response to Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created  (Melvin Davidson <melvin6925@gmail.com>)
Responses Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created
Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created
List pgsql-general
On Wed, Apr 20, 2016 at 4:40 PM, Melvin Davidson <melvin6925@gmail.com> wrote:

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

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Function PostgreSQL 9.2
Next
From: Adrian Klaver
Date:
Subject: Re: Function PostgreSQL 9.2