Re: [PATCH] Fix leaky VIEWs for RLS

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [PATCH] Fix leaky VIEWs for RLS
Дата
Msg-id 4C093BE8.2040200@enterprisedb.com
обсуждение исходный текст
Ответ на Re: [PATCH] Fix leaky VIEWs for RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Fix leaky VIEWs for RLS  (Robert Haas <robertmhaas@gmail.com>)
Re: [PATCH] Fix leaky VIEWs for RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 04/06/10 17:33, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> On 04/06/10 07:57, Tom Lane wrote:
>>> The proposal some time back in this thread was to trust all built-in
>>> functions and no others.
>
>> I thought I debunked that idea already
>> (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not
>> all built-in functions are safe. Consider casting integer to text, for
>> example.

(I meant "text to integer", of course)

> Maybe the entire idea is unworkable.  I certainly don't find any comfort
> in your proposal in the above-referenced message to trust index
> operators; where is it written that those don't throw errors?

Let's consider b-tree operators for an index on the secure table, for 
starters. Surely a b-tree index comparison operator can't throw an error 
on any value that's in the table already, you would've gotten an error 
trying to insert that.

Now, is it safe to expand that thinking to b-tree operators in general, 
even if there's no such index on the table? I'm not sure. But indexable 
operations are what we care about the most; the order of executing those 
determines if you can use an index scan or not.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Idea for getting rid of VACUUM FREEZE on cold pages