Re: leaky views, yet again

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: leaky views, yet again
Дата
Msg-id AANLkTinqFy77sjwY+BDotVYSYNvYV-+a0fJod=9BPDNK@mail.gmail.com
обсуждение исходный текст
Ответ на Re: leaky views, yet again  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Ответы Re: leaky views, yet again  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
2010/10/5 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> The term "built-in functions" means functions written in INTERNAL language
>> here. But we also have SQL functions by default. Some of them are just a
>> wrapper to internal functions. I'm not sure the checking of INTERNAL language
>> is the best way for the purpose. Did you compare it with other methods?
>> For example, "oid<  FirstNormalObjectId" looks workable for me.
>>
> Hmm. I'm not sure they can be used for index-scans. If these operators are not
> corresponding to index-scans, I want to keep the logic to check INTERNAL language,
> because these have obviously no side effects (= not leakable anything).

I think the idea that all internal operators are safe has been
thoroughly discredited already.

> Hmm. It might be better than ad-hoc enhancement of StdRdOptions.
> BTW, which is more preference to store the flag of security view:
> reloption of the view or a new bool variable in the pg_class?
>
> I tried to store this flag within reloptions to minimize the patch
> size, but it seems to me reloption support for views makes the patch
> size larger in the result.

I think a boolean in pg_class is the way to go.  Is there a padding
byte we can steal, to avoid making the fixed-size portion larger?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_filedump for 9.0?
Следующее
От: Devrim GÜNDÜZ
Дата:
Сообщение: Re: pg_filedump for 9.0?