Re: Infinite recursion in row-security based on updatable s.b. views

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Infinite recursion in row-security based on updatable s.b. views
Дата
Msg-id 52E76CD6.1010704@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Infinite recursion in row-security based on updatable s.b. views  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: Infinite recursion in row-security based on updatable s.b. views  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 01/24/2014 07:16 PM, Dean Rasheed wrote:
> think recursively calling the rewriter
> to expand view references in the new RLS qual, and
> expand_security_qual() to expand any additional RLS quals in the
> securityQuals list

With this, it'd be helpful if expand_security_qual(...) took a
RangeTblEntry instead of an rt_index.

That'd also be much more efficient with large rtables if we can arrange
a scan through the rtable when looking for security quals.

Like other places that operate on the rangetable while it's being
modified, we can walk the rangetable list up until the final entry that
existed when we started walking. This approach saves the series of
rt_fetch calls, which are something like O(n log n) for n relations.

It's safe because the operation will only append rangetable entries.

(I can't help wonder how much we'd gain by making the rtable an array
that gets doubled in size and copied whenever it overflows, rather than
a linked list, given all the walking of it that gets done, and how dead
entries to get flagged as dead rather than actually removed.)

I'm looking for where I found the code that already does this so I can
point and say "I'm not crazy, we already do it here". Will follow up
with a patch.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yugo Nagata
Дата:
Сообщение: Re: Fwd: Proposal: variant of regclass
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core