Re: leaky views, yet again

(2010/10/05 23:16), Robert Haas wrote:
> 2010/10/5 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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.
>
How can we distinguish an internal operator and others?
Because pg_operator does not have a property that we can use to
distinguish them, I tried to check function of the operators...

>> 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?
>
OK, I'll add a boolean in pg_class. Perhaps, 'relissecview'?

Thanks
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>