Re: Date created for tables

AFAICT, this is something that should have been designed into the initial
release of PostgreSQL, but rather than go down that road, I have thought
about this and will attempt to explain the "complexity" of implementing it,
which to date has only been described as too hard or, we don't have enough
developers or resources.

In order to record the CREATE and ALTER dates, it would require adding two
columns to pg_class. IE date_create & date_altered.
However, that being said, it would also then require a routine (or generic
routine) to populate those columns for EVERY system type that gets placed
in pg_class when created or altered. So tables, views, materialized views,
etc.

Now, AFAICT the implementation of new features has nothing to do with
complexity, but rather what has been determined to be required or desirable.

Indeed, there exists a feature request url, but AFAICT, little attention
has been payed to that url.

user feature request <https://postgresql.uservoice.com/forums/21853-general>

On Tue, Dec 24, 2019 at 10:11 PM Ron <ronljohnsonjr(at)gmail(dot)com> wrote:

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

--
*Melvin Davidson*
*Maj. Database & Exploration Specialist*
*Universe Exploration Command – UXC*
Employment by invitation only!