Wrong security context for deferred triggers?

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
DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW EXECUTE FUNCTION trig();

Create a role and allow it INSERT on the table:

CREATE ROLE duff;

GRANT INSERT ON tab TO duff;

Now become that role and try some inserts:

SET ROLE duff;

BEGIN;

INSERT INTO tab VALUES (1);
NOTICE: current_user = duff

That looks ok; the current user is "duff".

SET CONSTRAINTS ALL DEFERRED;

INSERT INTO tab VALUES (2);

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 somewhat nasty in combination with
SECURITY DEFINER functions: if that function performs an operation, and that
operation triggers a deferred trigger, that trigger will run in the wrong
security context.

This behavior looks buggy to me. What do you think?
I cannot imagine that it is a security problem, though.

Yours,
Laurenz Albe