From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | David Gould <daveg(at)sonic(dot)net> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Incomplete Explain for delete |
Date: | 2015-06-22 23:43:30 |
Message-ID: | CAKFQuwYbdaT_RGpAFx9Z28wDGLLAoY5NfT5nvF4TeXH=3g-NEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Jun 22, 2015 at 6:32 PM, David Gould <daveg(at)sonic(dot)net> wrote:
> On Mon, 22 Jun 2015 12:41:28 -0400
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> > Except that the query inside the trigger is known to system - the fact
> it
> > is wrapped in a trigger is an implementation detail that could, in
> theory,
> > be bypassed in order to facilitate a more meaningful explain output.
>
> Unless triggers are prohibited from using dynamic sql, the query really
> cannot be known to the system.
>
>
Maybe that is the case here as well but the code that is used in the FK
trigger is maintained by the core PostgreSQL project and seldom changes.
Having explain notice that an FK trigger is present and then applying some
discovery to determine the source table and columns of said FK trigger
seems theoretically possible. It does not look inside the trigger -
instead it is explicitly told what a FK trigger does.
I am strictly considering FK triggers here - no other kind and especially
not user-defined ones.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2015-06-23 01:00:43 | Re: BUG #13440: unaccent does not remove all diacritics |
Previous Message | Tom Lane | 2015-06-22 23:08:28 | Re: BUG #13462: Impossible to use COPY FORMAT BINARY in chunks through libpq |