Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created
| От | Shulgin, Oleksandr |
|---|---|
| Тема | Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created |
| Дата | |
| Msg-id | CACACo5TGjGSK6EEpHsbydHUZu+ZFZhXiqMYnZ85RKbo9LPQ6ow@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add relcreated (timestamp) column to pg_class catalog to record the time an object was created (Melvin Davidson <melvin6925@gmail.com>) |
| Ответы |
Re: Add relcreated (timestamp) column to pg_class catalog
to record the time an object was created
(Melvin Davidson <melvin6925@gmail.com>)
|
| Список | pgsql-general |
On Thu, Apr 21, 2016 at 6:55 PM, Melvin Davidson <melvin6925@gmail.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 attentionis 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
В списке pgsql-general по дате отправления:
Предыдущее
От: Yury ZhuravlevДата:
Сообщение: Re: I need testers for incremental backups (similar Oracle)