That seems straightforward. Unfortunately I also want to know the user/role that performed the operation. If I use SECURITY DEFINER, I get the superuser account back from CURRENT_USER, not the actual user.
Sorry, should have included that in the original email. How do I restrict access while still retaining info about the current user/role?
On Mon, Jun 17, 2019 at 5:47 PM <raf@raf.org> wrote:
Adrian Klaver wrote:
> On 6/17/19 4:54 PM, Miles Elam wrote: > > Is there are way to restrict direct access to a table for inserts but > > allow a trigger on another table to perform an insert for that user? > > > > I'm trying to implement an audit table without allowing user tampering > > with the audit information. > > Would the below not work?: > CREATE the table as superuser or other privileged user > Have trigger function run as above user(use SECURITY DEFINER)
and make sure not to give any other users insert/update/delete permissions on the audit table.