On Thu, Sep 1, 2016 at 12:12 AM, Vik Fearing <v...@2ndquadrant.fr> wrote: > Part of what people want this for is to audit what people *try* to do. > We can already audit what they've actually done. > > With your solution, we still wouldn't know when an unauthorized attempt > to do something happened.
The unauthorized attempt to execute the function will still be logged to the PostgreSQL log file since it would throw an error, just like trying to connect with e.g. an invalid username would be logged to the log files. I think that's enough for that use-case, since it's arguably not an application layer problem, since no part of the code was ever executed. But if someone tries to execute a function where one of the input params is a password and the function raises an exception if the password is incorrect and wants to log the unauthorized attempt, then that would be a good example of when you could use and would need to use autonomous transactions to log the invalid password attempt. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers