On 04/20/2016 02:40 PM, Melvin Davidson wrote:
>
> On Wed, Apr 20, 2016 at 5:14 PM, David G. Johnston
>
>
> Really, it's that hard to add another column to an existing system
> catalog and document it? Hmm, let's try
> ALTER TABLE pg_catalog.pg_class ADD COLUMN relcreatedat timestamp
> default now();
> Documentation
> Name Type
> References Descriptionrelcreatedat | timestamp | |
> The date and time the object was initially created
>
> Gee, that took over 4 minutes, I guess it is really is hard to do
> this... NOT.
No one is arguing that slapping a new column on pg_class is not easy,
just that the implications of doing so requires a good deal of thought.
The first thing that comes to my mind(also in threads on --hackers) is
what is the creation time?:
The first time an object was ever created?
The time it was created in a new database during a
dump-restore/pg_upgrade/replication?
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 do not have the capability of adding my own patch, but certainly is is
> not that hard to add one new column of type timestamp with a default of
> now() to the existing pg_class system catalog. I have already statedthe
> logic/reason/need behind it in my initial request, both today and years
> ago. as for Tom Lane saying that a forthcoming audit log will fulfill
> this request it is not completely true. An audit log will require
> additional code for reviewing, whereas a simple SQL query would be able
> to determine creation date if the column is added as requested, as per
> my previous support post on Oracle and SQL Server capability.
>
> 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.
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize. Whether or not you
> wish to share my fantasy is entirely up to you.
--
Adrian Klaver
adrian.klaver@aklaver.com