Re: Improving RLS planning
От | Tom Lane |
---|---|
Тема | Re: Improving RLS planning |
Дата | |
Msg-id | 19643.1478616318@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Improving RLS planning (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Improving RLS planning
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> * Since the planner is now depending on Query.hasRowSecurity to be set >> whenever there are any securityQuals, I put in an Assert about that, >> and promptly found three places in prepjointree.c and the rewriter where >> we'd been failing to set it. I have not looked to see if these represent >> live bugs in existing releases, but they might. Or am I misunderstanding >> what the flag is supposed to mean? > They're independent, actually. securityQuals can be set via either > security barrier view or from RLS, while hasRowSecurity is specifically > for the RLS case. The reason for the distinction is that changing your > role isn't going to impact security barrier views at all, while it could > impact what RLS policies are used. See extract_query_dependencies(). OK. In that case I'll need to adjust the patch so that the planner keeps its own flag about whether the query contains any securityQuals; that's easy enough. But I'm still suspicious that the three places I found may represent bugs in the management of Query.hasRowSecurity. regards, tom lane
В списке pgsql-hackers по дате отправления: