From: | Mitar <mmitar(at)gmail(dot)com> |
---|---|
To: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: In which session context is a trigger run? |
Date: | 2018-12-31 12:22:20 |
Message-ID: | CAKLmikPXcRTPOBkKi1RGq4sXV9kxoxFY_zgOeXjRZ4Ch0BAFWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi!
On Mon, Dec 31, 2018 at 2:58 AM Peter J. Holzer <hjp-pgsql(at)hjp(dot)at> wrote:
> On 2018-12-30 08:56:13 -0800, Adrian Klaver wrote:
> > On 12/30/18 3:08 AM, Peter J. Holzer wrote:
> > > If I understood Mitar correctly he wants the trigger to execute in the
> > > session where it was declared, not in the sessio where the statement was
> > > executed that triggered the trigger.
> >
> > There is the additional hitch that the trigger is being declared to use a
> > temporary function that is defined in an alias schema pg_temp.
>
> Yeah, but that would be neatly solved by the magic teleportation of the
> trigger execution. (I think this is actually how he got the idea that
> executing the trigger in a different session would solve his problem.)
Thanks for understanding well what I am asking. Yes, it seems some
form of sending around triggers would be needed. I do not really care
if those triggers would run after transaction is committed. So they
should be some REALLY AFTER triggers. :-)
For now I am using NOTIFY/LISTEN to send information to the client
which then dispatches it to current connection/session. It allows me
also to batch multiple trigger calls together.
Mitar
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Korot | 2018-12-31 16:14:30 | Re: libpq bug? |
Previous Message | Mitar | 2018-12-31 12:18:45 | Re: In which session context is a trigger run? |