On Sat, 2024-06-08 at 17:36 -0400, Joseph Koshakow wrote:
> I see that this patch is marked as ready for review, so I thought I
> would attempt to review it. This is my first review, so please take it
> with a grain of salt.
Thank you. Your review is valuable and much to the point.
>
> It
On Sat, Jun 8, 2024 at 10:13 PM Isaac Morland
wrote:
> Speaking as a table owner, when I set a trigger on it, I expect that when
the specified actions occur my trigger will fire and will do what I
specify, without regard to the execution environment of the caller
(search_path in particular); and
On Sat, 8 Jun 2024 at 17:37, Joseph Koshakow wrote:
> However, I do worry that this is too much of a breaking change and
> fundamentally changes how triggers work. Another draw back is that if
> the trigger owner loses the required privileges, then no one can modify
> to the table.
>
I worry
On Sat, Jun 8, 2024 at 5:36 PM Joseph Koshakow wrote:
>Additionally, I applied your patch to master and re-ran the example and
>didn't notice any behavior change.
>
>test=# CREATE TABLE tab (i integer);
>CREATE TABLE
>test=# CREATE FUNCTION trig() RETURNS trigger
Hi,
I see that this patch is marked as ready for review, so I thought I
would attempt to review it. This is my first review, so please take it
with a grain of salt.
> So a deferred constraint trigger does not run with the same security
context
> as an immediate trigger.
It sounds like the crux
On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> On 11/6/23 14:23, Laurenz Albe wrote:
> > This behavior looks buggy to me. What do you think?
> > I cannot imagine that it is a security problem, though.
>
> How could code getting executed under the wrong role not be a security
> issue?
On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> On 11/6/23 14:23, Laurenz Albe wrote:
> > This behavior looks buggy to me. What do you think?
> > I cannot imagine that it is a security problem, though.
>
> How could code getting executed under the wrong role not be a security
> issue?
On 11/6/23 14:23, Laurenz Albe wrote:
> ...
>
> This behavior looks buggy to me. What do you think?
> I cannot imagine that it is a security problem, though.
>
How could code getting executed under the wrong role not be a security
issue? Also, does this affect just the role, or are there some
On Mon, 6 Nov 2023 at 11:58, Laurenz Albe wrote:
> Become a superuser again and commit:
> >
> > RESET ROLE;
> >
> > COMMIT;
> > NOTICE: current_user = postgres
> >
> >
> > So a deferred constraint trigger does not run with the same security
> context
> > as an immediate trigger. This is
On Mon, 2023-11-06 at 14:23 +0100, Laurenz Albe wrote:
> CREATE FUNCTION trig() RETURNS trigger
> LANGUAGE plpgsql AS
> $$BEGIN
> RAISE NOTICE 'current_user = %', current_user;
> RETURN NEW;
> END;$$;
>
> CREATE CONSTRAINT TRIGGER trig AFTER INSERT ON tab
> DEFERRABLE
Create a table and a deferrable constraint trigger:
CREATE TABLE tab (i integer);
CREATE FUNCTION trig() RETURNS trigger
LANGUAGE plpgsql AS
$$BEGIN
RAISE NOTICE 'current_user = %', current_user;
RETURN NEW;
END;$$;
CREATE CONSTRAINT TRIGGER trig AFTER INSERT ON tab
11 matches
Mail list logo
