Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Melvin Davidson <melvin6925(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created
Date: 2016-04-22 16:49:41
Message-ID: CACACo5TGjGSK6EEpHsbydHUZu+ZFZhXiqMYnZ85RKbo9LPQ6ow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Apr 21, 2016 at 6:55 PM, Melvin Davidson <melvin6925(at)gmail(dot)com>
wrote:

> And so far, NO ONE has shown any proof that this enhancement could
> possibly cause ANY negative result.
>

Searching through the list archives[1] I can see that you've asked this
question a number of times already. And I'm pretty sure it was asked quite
a number of times by the others.

IMO, every time it was conclusively demonstrated that when you consider
dump/restore semantics, this feature can have exactly zero value if
implemented *inside pg_catalog*. And it would have to be a pretty invasive
change (it's not enough to just add the attribute, you also need to touch
probably a dozen of places where it will be populated or read), so without
any positive effect it results in negative effect overall.

> All that has been presented so far are corner cases where this "might" not
> be useful.
> If the PostgreSQL developers are really worried about unexpected
> drawbacks, then, based on that, ALL future development should stop
> immediately.
> This is total insanity! I am asking for a simple, safe enhancement that
> would add what compatibility with what is already in other databases, yet
> everyone seems to be terrified about it.
> We have already modified system catalogs previously with no ill effect.
>

I believe system catalogs are modified on a regular basis with every major
release. But in every instance there has to be a good reason for a change.

So please, someone present a logical explanation of why this should not be
> done, or how it will negatively impact the PostgreSQL project.
> If you cannot do so, then start thinking positively.
>

As said before a number of times: what you propose looks easy, but it's
just the tip of an iceberg. Even if the community comes to an agreement
what dump/restore semantics should be and it is implemented, the feature is
still not *that* useful on its own to justify its existence (no, I don't
buy the example of "DELETE/DROP TABLE" based on relcreated field. Do you,
by chance, have any other use case?)

Apart from created timestamp would you not like to also know the user/role
who has created it? What about updates (using ALTER TABLE)--would you want
to know when that *last* happened and who did that? Would you want to know
what exactly was altered? Would you want to know the history *before* the
last update? Finally, if someone drops the table, you can say good bye to
its pg_catalog records and there's no hope to know who did that and when
(or if that table has even existed to start with).

When you just start thinking in this direction, it becomes apparent that a
proper audit solution is a much better fit to tackle these problems. There
are features continuously added in the recent releases that will facilitate
building such solutions in form of extensions: DDL event triggers and
Logical decoding, to name a few.

Previous to yesterday, nowhere on the PostgreSQL site was it stated WHERE
> to present enhancement requests.
>

There is plenty of information on PostgreSQL sites about this[2,3,4]. Are
you suggesting something was add yesterday on top of that?

Now that it has been verified this is the correct list,
>

Probably it is the most appropriate one, unless you have the patch ready
(then it would be for -hackers). I'm still puzzled as to how have you
found that completely unrelated feature request voting site given the
abundance of information on the official sites and lack of links to that
site from there.

It is true that some visibility of what majority of users consider to be
the most useful enhancement could benefit the project, but it has to be
maintained by the community in order to provide some value. Otherwise it
is going to have only the negative impact: an impression that PostgreSQL
developers doesn't listen to the users.

There still exists no formal requirements for presenting an enhancement
> request.
>

Just follow the requirements for a good problem report, especially[5].
After all you have a problem of a missing feature, right?

> WHY am I being vilified for making a simple request? How is it that
> developers proceed with other enhancements, yet so much negative attention
> is being given to my request because of unjustified fear that something
> bad will happen?
>

Less colorful^W^W plain text mails without top-posting might help here.
Seriously, not everyone has the time to present the same arguments over and
over again: searching the archives should have given you some perspective
on the destiny of this feature request.

Should we really put this on Todo with a mark that we actually don't want
it?

Regards,
--
Alex

[1] http://www.postgresql.org/search/?m=1&q=relcreated
[2] http://www.postgresql.org/support/
[3] https://wiki.postgresql.org/wiki/FAQ#Where_can_I_get_support.3F
[4] https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
[5]
https://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-04-22 17:11:39 Re: Enhancement request for pg_dump
Previous Message Pierre Chevalier Géologue 2016-04-22 16:45:45 Re: Enhancement request for pg_dump