Re: leaky views, yet again - Mailing list pgsql-hackers

From Robert Haas
Subject Re: leaky views, yet again
Date
Msg-id AANLkTinqFy77sjwY+BDotVYSYNvYV-+a0fJod=9BPDNK@mail.gmail.com
Whole thread Raw
In response to Re: leaky views, yet again  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: leaky views, yet again
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_filedump for 9.0?
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: pg_filedump for 9.0?