Yep.
Still "created" once - instantiated repeated times, but "created" once. Try federated metadata records.... only one "original creation date" which is an explicit attribute of a record. Last copied, updated, edited are different.
Creation date can be when first entered into a spreadsheet, or written down... insert date pertains to "creation of the record as a database tuple", etc...
A replica can be copied - but that is a date this instance was created, not the original record.
One question - does an edit explicitly destroy the original object and create a new (child? linked?) object, or a modified version of the original? Answer "yeah/nah" - whichever you decide is correct for your use case - there no universal yes or no answer.
The real issue is confusion about what "created" means - for data audit tracking/provenance, etc - very important in best practice data mgmt in many domains - all these are dates representing different actions which can be defined & maintained - but by the user rather than the system (albeit often by triggers representing local business rules). Postgres has all the tools you need to implement whatever audit trails you need for create (when first written on a piece of paper), inserts, updates/edits, etc... but doing this in a standard way to meet all users needs is a long standing, unsolved & probably unsolvable issue.
Brent Wood
Programme leader: Environmental Information Delivery
NIWA
DDI: +64 (4) 3860529
Still "created" once - instantiated repeated times, but "created" once. Try federated metadata records.... only one "original creation date" which is an explicit attribute of a record. Last copied, updated, edited are different.
Creation date can be when first entered into a spreadsheet, or written down... insert date pertains to "creation of the record as a database tuple", etc...
A replica can be copied - but that is a date this instance was created, not the original record.
One question - does an edit explicitly destroy the original object and create a new (child? linked?) object, or a modified version of the original? Answer "yeah/nah" - whichever you decide is correct for your use case - there no universal yes or no answer.
The real issue is confusion about what "created" means - for data audit tracking/provenance, etc - very important in best practice data mgmt in many domains - all these are dates representing different actions which can be defined & maintained - but by the user rather than the system (albeit often by triggers representing local business rules). Postgres has all the tools you need to implement whatever audit trails you need for create (when first written on a piece of paper), inserts, updates/edits, etc... but doing this in a standard way to meet all users needs is a long standing, unsolved & probably unsolvable issue.
Brent Wood
Programme leader: Environmental Information Delivery
NIWA
DDI: +64 (4) 3860529
| Brent Wood |
| Principal Technician - GIS and Spatial Data Management Programme Leader - Environmental Information Delivery |
| +64-4-386-0529 | 301 Evans Bay Parade, Greta Point, Wellington | www.niwa.co.nz |
 |
| To ensure compliance with legal requirements and to maintain cyber security standards, NIWA's IT systems are subject to ongoing monitoring, activity logging and auditing. This monitoring and auditing service may be provided by third parties. Such third parties can access information transmitted to, processed by and stored on NIWA's IT systems. |
________________________________________
From: pgsql-general-owner@xxxxxxxxxxxxxx [pgsql-general-owner@xxxxxxxxxxxxxx] on behalf of Tom Lane [tgl@xxxxxxxxxxxxx]
Sent: Wednesday, May 13, 2015 11:26 AM
To: Melvin Davidson
Cc: Adrian Klaver; pgsql-general@xxxxxxxxxxxxxx
Subject: Re: Why is there no object create date is the catalogs?
Melvin Davidson <melvin6925@xxxxxxxxx> writes:
> You are over thinking this. An object is only "created" once!
Yeah? Would you expect that pg_dump followed by pg_restore would preserve
the original creation date? What about pg_upgrade?
This has come up many times before, and we've always decided that it was
not as simple as it seems at first glance, and that it would be difficult
to satisfy all use-cases. Try searching the archives for previous threads.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
From: pgsql-general-owner@xxxxxxxxxxxxxx [pgsql-general-owner@xxxxxxxxxxxxxx] on behalf of Tom Lane [tgl@xxxxxxxxxxxxx]
Sent: Wednesday, May 13, 2015 11:26 AM
To: Melvin Davidson
Cc: Adrian Klaver; pgsql-general@xxxxxxxxxxxxxx
Subject: Re: Why is there no object create date is the catalogs?
Melvin Davidson <melvin6925@xxxxxxxxx> writes:
> You are over thinking this. An object is only "created" once!
Yeah? Would you expect that pg_dump followed by pg_restore would preserve
the original creation date? What about pg_upgrade?
This has come up many times before, and we've always decided that it was
not as simple as it seems at first glance, and that it would be difficult
to satisfy all use-cases. Try searching the archives for previous threads.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
