Re: [v9.2] Fix Leaky View Problem

I updated the patches of fix-leaky-view problem, according to the
previous discussion.
The "NOLEAKY" option was replaced by "LEAKPROOF" option, and several regression
test cases were added. Rest of stuffs are unchanged.

For convenience of reviewer, below is summary of these patches:

The Part-1 implements corresponding SQL syntax stuffs which are
"security_barrier"
reloption of views, and "LEAKPROOF" option on creation of functions to be stored
new pg_proc.proleakproof field.

The Part-2 tries to tackles a leaky-view scenarios by functions with
very tiny cost
estimation value. It was same one we had discussed in the commitfest-1st.
It prevents to launch functions earlier than ones come from inside of views with
"security_barrier" option.

The Part-3 tries to tackles a leaky-view scenarios by functions that references
one side of join loop. It prevents to distribute qualifiers including
functions without
"leakproof" attribute into relations across security-barrier.

Thanks,

2011/9/7 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2011/9/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Noah Misch <noah(at)leadboat(dot)com> writes:
>>> I liked NOLEAKY for its semantics, though I probably would have spelled it
>>> "LEAKPROOF".  PostgreSQL will trust the function to implement a specific,
>>> relatively-unintuitive security policy.  We want the function implementers to
>>> read that policy closely and not rely on any intuition they have about the
>>> "trusted" term of art.  Our use of TRUSTED in CREATE LANGUAGE is more
>>> conventional, I think, as is the trusted nature of SECURITY DEFINER.  In that
>>> vein, folks who actually need SECURITY DEFINER might first look at TRUSTED;
>>> NOLEAKY would not attract the same unwarranted attention.
>>
>> I agree that TRUSTED is a pretty bad choice here because of the high
>> probability that people will think it means something else than what
>> it really means.  LEAKPROOF isn't too bad.
>>
> It seems to me LEAKPROOF is never confusable for everyone, and
> no conflicts with other concept, although it was not in my vocaburary.
>
> If no better idea anymore, I'll submit the patch again; with LEAKPROOF keyword.
>
> Thanks,
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>

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