On 10/30/2013 11:25 AM, Kohei KaiGai wrote:
+
+ /*
+* Row-level security should be disabled in case when foreign-key
+* relation is queried to check existence of tuples that references
+* the primary-key being modified.
+*/
+ temp_sec_context = save_sec_context |
During my testing of Kohei KaiGai's row-security patches I've been
looking into how foreign keys should be and are handled. There are some
interesting wrinkles around FK cascades, the rights under which FK
checks execute, and about the consistency effects of changing or
applying an RLS policy.
It
On 10/29/2013 04:09 PM, Craig Ringer wrote:
Problem is, that won't necessarily happen, because the FK check is run
with the rights of the table owner.
Some further reading suggests that another vendor's implementation
ignores row security policy for foreign key constraint checks. So FK
Craig Ringer cr...@2ndquadrant.com writes:
During my testing of Kohei KaiGai's row-security patches I've been
looking into how foreign keys should be and are handled. There are some
interesting wrinkles around FK cascades, the rights under which FK
checks execute, and about the consistency
2013/10/29 Tom Lane t...@sss.pgh.pa.us:
Craig Ringer cr...@2ndquadrant.com writes:
During my testing of Kohei KaiGai's row-security patches I've been
looking into how foreign keys should be and are handled. There are some
interesting wrinkles around FK cascades, the rights under which FK
Tom Lane-2 wrote
Craig Ringer lt;
craig@
gt; writes:
During my testing of Kohei KaiGai's row-security patches I've been
looking into how foreign keys should be and are handled. There are some
interesting wrinkles around FK cascades, the rights under which FK
checks execute, and about the
On 10/29/2013 10:01 PM, Tom Lane wrote:
As I recall, I've been saying since day one that row-level security cannot
sensibly coexist with foreign-key constraints, and I've been told that the
potential users of such a feature don't care. I'm glad to see somebody
else complaining.
I'm
On 10/29/2013 11:21 PM, Kohei KaiGai wrote:
My vote is, system should keep referencial integrity as if RLS policy is
not configured. It is more fundamental stuff than RLS policy per user
basis.
I agree, and right now that is not how it works, causing some pretty
confusing behaviour.
--
Craig Ringer cr...@2ndquadrant.com writes:
I'd kind of like to see FK constraints affected by RLS for
non-superusers, at least as an option.
I think that's a complete nonstarter. Aside from the fact that such a
constraint will have no definable semantics, even the possibility that a
constraint
On 10/30/2013 10:50 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
I'd kind of like to see FK constraints affected by RLS for
non-superusers, at least as an option.
I think that's a complete nonstarter. Aside from the fact that such a
constraint will have no definable
2013/10/30 Craig Ringer cr...@2ndquadrant.com:
On 10/30/2013 10:50 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
I'd kind of like to see FK constraints affected by RLS for
non-superusers, at least as an option.
I think that's a complete nonstarter. Aside from the fact that
On 10/30/2013 11:25 AM, Kohei KaiGai wrote:
2013/10/30 Craig Ringer cr...@2ndquadrant.com:
On 10/30/2013 10:50 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
I'd kind of like to see FK constraints affected by RLS for
non-superusers, at least as an option.
I think that's a
12 matches
Mail list logo
