Re: [HACKERS] Row Level Security UPDATE Confusion
От | Joe Conway |
---|---|
Тема | Re: [HACKERS] Row Level Security UPDATE Confusion |
Дата | |
Msg-id | a6e66bd3-8d84-5afc-70b7-7cac0aece35f@joeconway.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Row Level Security UPDATE Confusion (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] Row Level Security UPDATE Confusion
|
Список | pgsql-hackers |
On 04/13/2017 01:31 PM, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor <rod.taylor@gmail.com> wrote: >> > I'm a little confused on why a SELECT policy fires against the NEW record >> > for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem >> > to have that restriction. >> >> My guess is that you have found a bug. > > Indeed. Joe's been looking into it and I'm hoping to find some time to > dig into it shortly. >> CREATE POLICY split_select ON t FOR SELECT TO split >> USING (value > 0); >> CREATE POLICY split_update ON t FOR UPDATE TO split >> USING (true) WITH CHECK (true); Yes -- from what I can see in gdb: 1) add_with_check_options() adds both (value > 0) and (true) to withCheckOptions -- this seems correct as the USING expression is used for WITH CHECK when the latter is not specified 2) ExecWithCheckOptions() checks (value > 0) which fails, and it immediately throws an ERROR, i.e. it never checks the (true) expression and therefore never ORs the results -- this seems incorrect, it uses restrictive not permissive Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
В списке pgsql-hackers по дате отправления: