| My code example ended up quite big—so I'll show it to you all only if you ask. But it's easy to describe. My script does this: 1. It creates three non-superuser roles: "data", "code", and "client". 2. It creates a text-book masters-and-details table pair with owner "data". Each table has the obvious PK column. The "details" table has the obvious FK column. And each table has a payload column "v". The FK constraint is defined thus: constraint details_fk foreign key(mk) references masters(mk) match full on delete cascade on update restrict initially deferred 3. It creates a DELETE trigger at each timing point on each table. That's eight in all: [before|after] * [row|statement] * [masters|details]. The trigger functions have the same names as the triggers. And each name pair reflects the three degrees of freedom—for example "before_statement_masters". Each trigger function simply does a "raise info" to report its name, the return value from "current_role", (and, in the "row" case, the value of "old.v"). And then it does "return null". The trigger functions are owned by "data" and are explicitly marked "security invoker". (The results are the same without this marking—as expected.) (In my real use case, the trigger functions are marked "security definer". But I did this test in order to understand the rules.) "data" grants appropriate privileges to "code" to let its functions succeed. 4. It creates three "security definer" procedures with owner "code" "cr_m_and_ds()" inserts specified "details" rows and then their specified "masters" row. (That's why the FK constraint is "initially deferred". The use-case from which this test is derived needs this.) "del_m()" deletes a specified "masters" row—which implies the cascade-delete of its details. "del_ds()" deletes all the "details" rows for a specified master. "code" grants "execute" on these to "client". ("client " owns no objects.) 5. "client" invokes "code.cr_m_and_ds()". It's called to insert a single "masters" row with "masters.v" set to 'Mary' and a single "details" row with "details.v" set to 'shampoo'. 6. "client" invokes "code.del_m()" on 'Mary'. Here's what I see: before_statement_masters: [code] before_row_masters: [code] Mary before_statement_details: [data] before_row_details: [data] shampoo after_row_masters: [code] Mary after_statement_masters: [code] after_row_details: [code] shampoo after_statement_details: [code] (I stripped the noisy "psql:0.sql:32: INFO:" preamble for each output line by hand.) I was surprised that the value from "current_role" is *not* the table owner, "data", in all cases. (This is how triggers behave in Oracle database.) Rather, it's mainly (but not always) "code". I could be persuaded that, in the cascade-delete case, the invoking role is the owner of the "masters" table rather than the role, "code" that performs the "delete" from "masters"—but that would maybe be a stretch. Anyway, if this is the intention, why is it like this only for the "before" timing points for the triggers on "details"? 7. Starting with the same 'Mary'-'shampoo' pair, client invokes "code.del_ds()" on 'Mary' With the same set-up, and using this instead of "del_m()", this is the result: before_statement_details: [code] before_row_details: [code] shampoo after_row_details: [code] shampoo after_statement_details: [code] Here the value for "current_role" from each trigger is the same. These results are in line with the common case in the first test. I read the section "Triggers on Data Changes" (https://www.postgresql.org/docs/current/plpgsql-trigger.html#PLPGSQL-DML-TRIGGER). But there's no hit on the page for any of "security", "invoker", or "definer". And I couldn't find wording without these terms that addresses what I describe here. |
