Re: autonomous transactions

From: Joel Jacobson <joel(at)trustly(dot)com>
To: Vik Fearing <vik(at)2ndquadrant(dot)fr>
Cc: Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autonomous transactions
Date: 2016-09-01 18:19:26
Message-ID: CAASwCXcvwsndWguEga97p5eHikwGQ5D0eLqHWxymr-1SHC8rKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 1, 2016 at 12:12 AM, Vik Fearing <vik(at)2ndquadrant(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2016-09-01 18:35:13 Re: autonomous transactions
Previous Message Tom Lane 2016-09-01 18:17:33 Re: \timing interval