From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Joseph Koshakow <koshy44(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Wrong security context for deferred triggers? |
Date: | 2024-06-26 09:02:30 |
Message-ID: | 8e8ef9739bdcc99d4e58916578a2d0a7b5c4268b.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2024-06-22 at 20:13 -0700, David G. Johnston wrote:
> [bikeshedding discussion about SQL syntax]
Sure, something like CREATE TRIGGER ... USING {INVOKER|CURRENT} ROLE
orsimilar would work, but think that this discussion is premature
at this point. If we have syntax to specify the behavior
of deferred triggers, that needs a new column in "pg_trigger", support
in pg_get_triggerdef(), pg_dump, pg_upgrade etc.
All that is possible, but keep in mind that we are talking about corner
case behavior. To the best of my knowledge, nobody has even noticed the
difference in behavior up to now.
I think that we should have some consensus about the following before
we discuss syntax:
- Does anybody depend on the current behavior and would be hurt if
my current patch went in as it is?
- Is this worth changing at all or had we better document the current
behavior and leave it as it is?
Concerning the latter, I am hoping for a detailed description of our
customer's use case some time soon.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-06-26 09:02:48 | Re: Conflict Detection and Resolution |
Previous Message | vignesh C | 2024-06-26 09:00:26 | Re: walsender.c comment with no context is hard to understand |