Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario - Mailing list pgsql-general

From Bryn Llewellyn
Subject Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario
Date
Msg-id 98604D47-FBA4-41FF-93D0-96167F1EC14D@yugabyte.com
Whole thread Raw
In response to Aw: Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Responses Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario
List pgsql-general
Karsten.Hilbert@gmx.net wrote:


I'll be happy to make a smaller example. It will, however, need to create… After all, how would I know which of the eight to skip while I don't know the intended rules for the current_role?

You'd certainly start out with all eight but then whittle down to what still exhibits the problem and post that.

Do you know where I can read a statement of the intended rules here? I appreciate that one is doomed who tries to deduce the rules that govern a software system's behavior by using just empirical testing. (And reading source code hoping to deduce the behavior that the programmer intended is hardly better.)

I used the subject "surprising results" to mean "Results that surprise me, Bryn". The results might well not surprise somebody who knows the rules. Several cases that I've asked about before on this list were surprising for me because I was too dim-witted to find where, in the PG docs, the rules were stated. And in those cases, I was delighted to be pointed to the appropriate doc and to receive some helpful instruction. That's what I'm hoping for here.

Notice that I didn't consider "for insert" or "for update" triggers. But you can contrive a cascade effect with these, too. For example, table "t1" might have a trigger that inserts or updates a row in table "t2" for a purpose like maintaining a change history. And "t2" might, in turn, have a trigger for who-knows-what purpose (maybe to enforce a write-once-read-many regime for the values in certain columns).

This is why I'd very much like to start by studying a clear statement of the intention in scenarios in the same general class as the one that I showed.

pgsql-general by date:

Previous
From: Igor Korot
Date:
Subject: Is ODBC list still alive?
Next
From: "David G. Johnston"
Date:
Subject: Re: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario