On Sat, Apr 23, 2016 at 3:17 PM, Melvin Davidson <melvin6925@xxxxxxxxx> wrote:
I am sorry you are disturbed, but thank you for pointing that out. I have revised my style to make you feel more comfortable.On Sat, Apr 23, 2016 at 1:03 AM, Shulgin, Oleksandr <oleksandr.shulgin@xxxxxxxxxx> wrote:>I find yor lack of proper email quoting skills disturbing..
Nothing to be sorry about, but I still don't see any improvement on your part :-/
>Yes, but that means that the timestamps must be part of the dump file, which means in turn they can be altered before the restore or--if implemented as separate commands like ALTER TABLE ... SET TIMESTAMP--at any point in time, so there is little to zero value in having the timestamps in the first place. This was already discussed in earlier threads.
No, when restoring to a new database, then by definition, object creation time is when they are loaded into the new database, which is essentially after the new database is created.
Well, that is the problem. By *your* definition that might be true, but not necessarily by anyone's else. Consider a DB restored from backup on a Saturday night due to server failure. All objects now have "outside of working hours" creation timestamps. Does that create more problems in your environment?
>> I also mentioned that this is already in the catalogs of Oracle and SQL Server.
>This sort of argument doesn't help the discussion: there should be a good reason to add the feature and merely pointing out that others already doing that is not a good reason, IMO.
Actually, it does. One of the reasons PostgreSQL is growing in popularity is that many companies are looking to switch away from Oracle and SQL Server and switch to open source PostgreSQL to save money. In doing so, consideratopn of the compatibilty and features is of prime concern.
Well, I can see some reason in that, but what we are discussing here is not a feature of primary concern, IMO.
>If rogue users can create objects in your schema you have bigger problems than tables created outside of working hours
...
>Your better bet is to keep rogue users out: using GRANTs and pg_hba.conf.
So you are saying users never be allowed to have access at late hours, or per business needs create their own sort tables?
At which point did you see me saying that? What I'm saying is that trying to monitor user actions after the fact when you suspect some of the users are "rogue" is not the best approach: it might be too late to review once damage is done. A better strategy is to use existing security mechanisms in PostgreSQL in order to prevent rogue users from logging in (pg_hba.conf) or perform undesirable actions (GRANT/REVOKE).
"Sort tables"?.. What is that?
The president of a company that works late would have a problem with that.
That was actually one of the points I was making: I see no harm in people working with the database outside of work hours. Sometimes it is necessary and frankly, the most important work quite often happens outside of hours. Moreover, it is not only the people that use the DB, what about applications?
Also, the same applies for developers in the development database, but sometimes they forget to drop experimental tables and/or document them.
I see absolutely no value in DBA reviewing anything in a dev database unless asked for specifically by developer.
The point is to be able to review without hindering.
My point would be to secure the system properly to avoid the constant need for "review". Or, if you are so concerned, setup a proper audit solution. None of these involves addition of "relcreated" attribute in pg_class.
>If you are going to review the logs anyway, why not just set log_statements=ddl and use logs
That is already done, but a SQL query is faster than a grep, awk and sort of a large log.
What stops you from importing the parsed log (I can recommend CSV format) to a DB and perform SQL queries on that? We already do that on a scale of hundreds of DB servers at my workplace, for example.
>No one is going to make even a "simple change" just for you to try
I am not asking for a change just for me, I am asking to consider the benefit to the PostgreSQL community.
That was done and so far no one has expressed any enthusiasm in having this feature exactly as suggested.
>the idea fails in practice due to all the other things you didn't think about.
Really, please state how this will not work. I believe I have successfully countered all negative arguments so far.
Not at all.
>you can make such a change for yourself and run a patched version for a while if you want--no one can stop you here.
I have already stated I cannot. I am not a C coder and attempting to ALTER the pg_class system catalog causes an error.
Commercial support is available for PostgreSQL from a plenty of "vendors". At times such commercial support can include writing a new feature into the database engine. I've heard that companies created around such commercial support usually employ some pretty qualified people. ;-)
I am hoping the PostgreSQL developers http://www.postgresql.org/community/contributors/ will review and either say yea or provide a specific reason for rejection.
A handful of reasons were given this time and when you've made this request earlier. I don't believe there is any justification in saying no specific reason was given.
Have a great day!
--
Alex
