Re: Table create time

On Thu, Aug 31, 2017 at 11:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Melvin Davidson <melvin6925(at)gmail(dot)com> writes:
> > Wolfgang, as David said, a column in pg_class for the creation time of a
> > table does not exist. I long ago requested that feature as it is
> > in other DB's (Oracle & MS SQL Server), but the main reason that it was
> not
> > done was that no one was interested in doing it.
>
> No, I'd say the big reason it hasn't happened is lack of consensus on
> details of how the feature should work --- notably, ought the creation
> date be preserved across a dump/restore? Doing that would require
> exposing some method to set the creation date from SQL, whereupon it loses
> value for some purposes because you can never be sure that what you're
> looking at is the "real" date and not something somebody frobbed later.
> OTOH, losing all your creation date info during dump/restore is annoying
> too.
>
> regards, tom lane
>

>lack of consensus on details of how the feature should work --- notably,
ought the creation
>date be preserved across a dump/restore?

Tom, I have already countered that there is no need to preserve a creation
date on dump/restore.

A. Only the creation time of an object is tracked, not mods.
B. When doing a dump, the catalogs (and relcreated time) are NOT included
in the dump.
C. When restoring an object that was deleted, or to a new database, the
relcreated = now();
D. When restoring data to an existing object, relcreated is not/cannot be
updated.

The _only_ time it would be a factor is restoring to a _new_ database. In
that case, C (from above) takes effect, as new tables/objects
are being created.

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.