Dean,
Thank you for catching that bug, I have updated the StackOverflow answer to
account for that issue.
As for the optimization problem I mentioned, the issue seems to be that
running a function that acquires a snapshot for each row is much slower
than in-lining a nested loop over table b into t
Dean,
Thank you for the pointer towards visibility/volatility. I think that
completely explains the effect that I am seeing in my repro. I
experimented with using a VOLATILE function for the SELECT RLS using
statement and while it completely solves my issue, it incurs too high a
cost for query ex
On Mon, 1 Oct 2018 at 21:45, Carl Sverre wrote:
> Dean,
> Thank you for the pointer towards visibility/volatility. I think that
> completely explains the effect that I am seeing in my repro. I experimented
> with using a VOLATILE function for the SELECT RLS using statement and while
> it comp
The real issue here is to do with the visibility of the data inserted
by the trigger function from within the same command. In general, data
inserted by a command is not visible from within that same command.
The easiest way to see what's going on is with a simple example.
Consider the following (
Thank you for the detailed report Charles. I think you may be missing the
“returning id” clause in the insert. Can you verify it works when you use
“returning id”? Thanks!
On Sun, Sep 30, 2018 at 7:57 PM Charles Clavadetscher (SwissPUG) <
clavadetsc...@swisspug.org> wrote:
> Hello
>
> On 30.09.201
Thanks for the initial results. Can you check that you are not using super
permissions and are enabling row security when running the test? Super
ignores row security.
Also yes, I forgot to add the policy names, sorry about that.
On Sun, Sep 30, 2018 at 1:34 AM Charles Clavadetscher (SwissPUG) <
c
An addition
On 01.10.2018 05:18:15, Charles Clavadetscher (SwissPUG)
wrote:
Hello
On 01.10.2018 05:00:02, Carl Sverre wrote:
Thank you for the detailed report Charles. I think you may be missing the
“returning id” clause in the insert. Can you verify it works when you use
“returning id”? Th
Hello
On 01.10.2018 05:00:02, Carl Sverre wrote:
Thank you for the detailed report Charles. I think you may be missing the
“returning id” clause in the insert. Can you verify it works when you use
“returning id”? Thanks!
[Charles] : You are right:
testuser@charles.localhost=> INSERT INTO a VAL
Hello
On 30.09.2018 23:31:32, Adrian Klaver wrote:
On 9/30/18 1:13 PM, Carl Sverre wrote:
> Thanks for the initial results. Can you check that you are not using
> super permissions and are enabling row security when running the test?
> Super ignores row security.
Yeah, big oops on my part, I was
On 9/30/18 1:13 PM, Carl Sverre wrote:
Thanks for the initial results. Can you check that you are not using
super permissions and are enabling row security when running the test?
Super ignores row security.
Yeah, big oops on my part, I was running as superuser. Running as
non-superuser result
Hello
On 29.09.2018 20:24:45, Adrian Klaver wrote:
On 9/28/18 11:35 PM, Carl Sverre wrote:
> *Context*
> I am using row-level security along with triggers to implement a pure
> SQL RBAC implementation. While doing so I encountered a weird behavior
> between INSERT triggers and SELECT row-level s
On 9/28/18 11:35 PM, Carl Sverre wrote:
*Context*
I am using row-level security along with triggers to implement a pure
SQL RBAC implementation. While doing so I encountered a weird behavior
between INSERT triggers and SELECT row-level security policies.
*Question*
I have posted a very detail
*Context*
I am using row-level security along with triggers to implement a pure SQL
RBAC implementation. While doing so I encountered a weird behavior between
INSERT triggers and SELECT row-level security policies.
*Question*
I have posted a very detailed question on StackOverflow here:
https://st
13 matches
Mail list logo
