Re: Date created for tables

On 12/24/19 8:58 PM, Rob Sargent wrote:
>
>> On Dec 24, 2019, at 11:48 AM, Ron <[email protected]> wrote:
>>
>>  On 12/24/19 1:14 PM, Rob Sargent wrote:
>>>> If there's not enough time and motivation for the developers to implement CREATED_ON and LAST_ALTERED in pg_class, then you should have said that in the first place.  We're adults; we understand that OSS projects have limited resources, and won't go off and pout in the corner.
>>>>
>>>> But that's not what y'all said.  "It's too complicated, mission creep, blah blah blah" just extended way too long.
>>> Is there a list of purported uses cases for these two attributes (other than auditing)?  Especially anything to do with managing the data as they currently exist?
>>
>> I've used last_altered for comparing tables on Staging and Prod database.
>>
>> If, for example, the last_altered on a prod table is *earlier* than 
>> last_altered on the staging table, then that's a *strong hint* that the 
>> staging and prod schema are out of sync, and more detailed examination is 
>> required.
>>
>> Another example is that -- since username is also recorded in other 
>> RDBMSs --it's useful when the customer is screaming at your boss asking 
>> who made that unauthorized modification to production that's breaking 
>> their application.  You then show them that the table hasn't been altered 
>> in X months, and point the finger back at their incompetent developers.
>>
>> All in all, it's not something that you use every day, but when it *is* 
>> useful, it's *very* useful.
>>
> Don’t both of those examples hi-light flaws in the release procedures?

And bug highlight flaws in the development process.  We're human, after all.

-- 
Angular momentum makes the world go 'round.