On Thu, Aug 31, 2017 at 11:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Melvin Davidson <melvin6...@gmail.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.
