Re: Date created for tables

On 12/24/19 8:58 PM, Rob Sargent wrote:
>
>> On Dec 24, 2019, at 11:48 AM, Ron <ronljohnsonjr(at)gmail(dot)com> 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.