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

From KaiGai Kohei
Subject Re: leaky views, yet again
Date
Msg-id 4CAB35BD.7090206@kaigai.gr.jp
Whole thread Raw
In response to Re: leaky views, yet again  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: leaky views, yet again
List pgsql-hackers
(2010/10/05 23:16), Robert Haas wrote:
> 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.
>
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@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch: SQL/MED(FDW) DDL
Next
From: Robert Haas
Date:
Subject: Re: patch: SQL/MED(FDW) DDL