Tom Lane wrote:
> On reflection what seems most likely is simply that turning these
> otherwise-inlineable SQL functions into SECURITY DEFINER disabled
> inline-ing them, resulting in catastrophic degradation of the
> generated plans, such that they took a lot longer than you were
> accustomed t
"Kevin Grittner" writes:
> ... It wasn't even clear to me that it was
> OK to have one security definer function call another, based on the
> code comment I quoted, so I didn't want to spend more hours on
> attempting to create a test case if it simply wasn't supported.
Yes, that's definitely *s
Tom Lane wrote:
> "Kevin Grittner" writes:
>> No comments on this?
>
> If there was a reproducible test case in your original message,
> I didn't see it, so I assumed you intended to investigate further
> on your own. It wasn't even clear to me that this was a Postgres
> bug rather than some er
"Kevin Grittner" writes:
> No comments on this?
If there was a reproducible test case in your original message,
I didn't see it, so I assumed you intended to investigate further
on your own. It wasn't even clear to me that this was a Postgres
bug rather than some error in your trigger logic.
No comments on this? It seems to me that at a minimum this needs
better documentation of a limitation, and the conditions under which
you hit the problem. I'm not sure there isn't an outright bug here.
We would like to flag all of our trigger functions as SECURITY
DEFINER, but there are triggers
PostgreSQL version 9.0.4, 64 bit.
Linux version 2.6.16.60-0.39.3-smp (geeko@buildhost)
(gcc version 4.1.2 20070115 (SUSE Linux))
#1 SMP Mon May 11 11:46:34 UTC 2009
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
We flagged some functions as SECURITY DEFINER and had queri
