On Wed, Feb 15, 2012 at 6:14 AM, Kohei KaiGai wrote:
> The attached patch is additional regression tests of ALTER FUNCTION with
> LEAKPROOF based on your patch.
> It also moves create_function_3 into the group with create_aggregate and so
> on.
Committed, thanks.
--
Robert Haas
EnterpriseDB: h
The attached patch is additional regression tests of ALTER FUNCTION with
LEAKPROOF based on your patch.
It also moves create_function_3 into the group with create_aggregate and so on.
Thanks,
2012/2/14 Kohei KaiGai :
> 2012/2/14 Robert Haas :
>> On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai wrot
2012/2/14 Robert Haas :
> On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai wrote:
>> I could not find out where is the origin of grammer conflicts, although
>> it does not conflict with any options within ALTER FUNCTION.
>>
>> Do you think the idea of ALTER ... NOT LEAKPROOF should be
>> integrated w
On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai wrote:
> I could not find out where is the origin of grammer conflicts, although
> it does not conflict with any options within ALTER FUNCTION.
>
> Do you think the idea of ALTER ... NOT LEAKPROOF should be
> integrated within v9.2 timeline also?
Yes.
2012/2/14 Robert Haas :
> On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai wrote:
>> I rebased the patch due to the updates of pg_proc.h.
>>
>> Please see the newer one. Thanks,
>
> Thanks, committed. I think, though, that some further adjustment is
> needed here, because you currently can't do ALTE
On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai wrote:
> I rebased the patch due to the updates of pg_proc.h.
>
> Please see the newer one. Thanks,
Thanks, committed. I think, though, that some further adjustment is
needed here, because you currently can't do ALTER FUNCTION ... NO
LEAKPROOF, which
On Sun, Jan 22, 2012 at 5:57 AM, Kohei KaiGai wrote:
>> This passes installcheck initially. Then upon second invocation of
>> installcheck, it fails.
>>
>> It creates the role "alice", and doesn't clean it up. On next
>> invocation alice already exists and cases a failure in test
>> select_views
On Sun, Jan 22, 2012 at 5:12 AM, Kohei KaiGai wrote:
> 2012/1/21 Robert Haas :
>> On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai wrote:
>>> I marked the default leakproof function according to the criteria that
>>> does not leak contents of the argument.
>>> Indeed, timestamp_ne_timestamptz() has
2012/1/21 Jeff Janes :
> On Tue, Jan 17, 2012 at 7:08 PM, Robert Haas wrote:
>> On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai wrote:
> I guess you concerned about that expected/select_views_1.out is
> patched, not expected/select_views.out.
> I'm not sure the reason why regression tes
On Tue, Jan 17, 2012 at 7:08 PM, Robert Haas wrote:
> On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai wrote:
I guess you concerned about that expected/select_views_1.out is
patched, not expected/select_views.out.
I'm not sure the reason why regression test script tries to make diff
>
On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai wrote:
> I marked the default leakproof function according to the criteria that
> does not leak contents of the argument.
> Indeed, timestamp_ne_timestamptz() has a code path that rises
> an error of "timestamp out of range" message. Is it a good idea
On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai wrote:
>>> I guess you concerned about that expected/select_views_1.out is
>>> patched, not expected/select_views.out.
>>> I'm not sure the reason why regression test script tries to make diff
>>> between results/select_views and expected/select_views_
On Sun, Jan 8, 2012 at 10:52 AM, Kohei KaiGai wrote:
>>> BTW, can you also resubmit the leakproof stuff as a separate patch for
>>> the last CF? Want to make sure we get that into 9.2, if at all
>>> possible.
>>>
>> Yes, it shall be attached on the next message.
>>
> The attached patch adds LEAKP
>> I guess you concerned about that expected/select_views_1.out is
>> patched, not expected/select_views.out.
>> I'm not sure the reason why regression test script tries to make diff
>> between results/select_views and expected/select_views_1.out.
>
> select_views.out and select_views_1.out are alt
On Tue, Jan 3, 2012 at 12:11 PM, Kohei KaiGai wrote:
> 2011/12/23 Robert Haas :
>> On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai wrote:
>>> I'd like the regression test on select_view test being committed also
>>> to detect unexpected changed in the future. How about it?
>>
>> Can you resend that
2011/12/23 Robert Haas :
> On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai wrote:
>> I'd like the regression test on select_view test being committed also
>> to detect unexpected changed in the future. How about it?
>
> Can you resend that as a separate patch? I remember there were some
> things I
On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai wrote:
> I'd like the regression test on select_view test being committed also
> to detect unexpected changed in the future. How about it?
Can you resend that as a separate patch? I remember there were some
things I didn't like about it, but I don't
2011/12/22 Robert Haas :
> On Mon, Dec 12, 2011 at 12:00 PM, Kohei KaiGai wrote:
>> The "v8.option-2" add checks around examine_simple_variable, and
>> prevent to reference statistical data, if Var node tries to reference
>> relation with security-barrier attribute.
>
> I adopted this approach, an
On Mon, Dec 12, 2011 at 12:00 PM, Kohei KaiGai wrote:
> The "v8.option-2" add checks around examine_simple_variable, and
> prevent to reference statistical data, if Var node tries to reference
> relation with security-barrier attribute.
I adopted this approach, and committed this.
--
Robert Haa
The attached patches are cut-off version based on the latest Robert's
updates. The "v8.regtest" adds regression test cases on variable
leaky-view scenarios with/without security-barrier property.
The "v8.option-1" add checks around restriction_selectivity, and prevent
to invoke estimator function
2011/12/9 Robert Haas :
> On Thu, Dec 8, 2011 at 5:17 PM, Kohei KaiGai wrote:
>> My first impression remind me an idea that I proposed before, even
>> though it got negative response due to user visible changes.
>> It requires superuser privilege to create new operators, since we
>> assume superus
On Thu, Dec 8, 2011 at 5:17 PM, Kohei KaiGai wrote:
> My first impression remind me an idea that I proposed before, even
> though it got negative response due to user visible changes.
> It requires superuser privilege to create new operators, since we
> assume superuser does not set up harmful con
2011/12/8 Robert Haas :
> On Sat, Dec 3, 2011 at 3:19 AM, Kohei KaiGai wrote:
>> I rebased my patch set. New functions in pg_proc.h prevented to apply
>> previous revision cleanly. Here is no functional changes.
>
> I was thinking that my version of this (attached to an email from
> earlier today)
On Sat, Dec 3, 2011 at 3:19 AM, Kohei KaiGai wrote:
> I rebased my patch set. New functions in pg_proc.h prevented to apply
> previous revision cleanly. Here is no functional changes.
I was thinking that my version of this (attached to an email from
earlier today) might be about ready to commit.
On Wed, Dec 7, 2011 at 1:45 PM, Tom Lane wrote:
>> One other possibility that comes to mind is that, instead of adding
>> "bool security_view" to the RTE, we could instead add a new RTEKind,
>> something like RTE_SECURITY_VIEW. That would mean going through and
>> finding all the places that refe
Robert Haas writes:
> Having looked at this more, I'm starting to believe KaiGai has this
> part right after all.
Yeah, you have a point. The rewriter is intentionally trying to make an
expanded view look just the same as an in-line SELECT-in-FROM, and we
need it to be easier to distinguish them
On Mon, Sep 26, 2011 at 3:59 PM, Tom Lane wrote:
> Kohei KaiGai writes:
>> Sorry, are you saying the current (in other words, rte->security_barrier
>> stores the state of reloption) approach is not a good idea?
>
> Yes. I think the same as Robert: the way to handle this is to store it
> in RelOp
I rebased my patch set. New functions in pg_proc.h prevented to apply
previous revision cleanly. Here is no functional changes.
2011/11/3 Kohei KaiGai :
> 2011/11/2 Tom Lane :
>> Kohei KaiGai writes:
>>> The reason why I redefined the relid of RangeTblEntry is to avoid
>>> the problem when securi
Kohei KaiGai writes:
> The reason why I redefined the relid of RangeTblEntry is to avoid
> the problem when security_barrier attribute get changed by concurrent
> transactions between rewriter and planenr stage.
This is complete nonsense. If the information is being injected into
the querytree b
2011/11/2 Robert Haas :
> On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai wrote:
>> [ new patch, with example query plans ]
>
> I like the look of those query plans.
>
> Redefining the RangeTblEntry's relid field to be valid for either a
> table or a subquery that originated from a view seems problem
On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai wrote:
> [ new patch, with example query plans ]
I like the look of those query plans.
Redefining the RangeTblEntry's relid field to be valid for either a
table or a subquery that originated from a view seems problematic to
me, though. For one thing,
On Fri, Oct 21, 2011 at 10:36 AM, Kohei KaiGai wrote:
> So, I will split the patch into two parts as follows, in the next commit fest.
>
> Part-1) Views with security_barrier reloption
>
> The part-1 portion provides views "security_barrier" reloption; that enables
> to keep sub-queries unflatten
So, I will split the patch into two parts as follows, in the next commit fest.
Part-1) Views with security_barrier reloption
The part-1 portion provides views "security_barrier" reloption; that enables
to keep sub-queries unflatten in the prepjoin.c stage.
In addition, these sub-queries (that ori
Robert Haas writes:
> Well, there's clearly some way to prevent pushdown from happening,
> because sticking a LIMIT in there does the trick...
I already pointed you at subquery_is_pushdown_safe ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Wed, Oct 19, 2011 at 6:35 AM, Kohei KaiGai wrote:
> 2011/10/19 Tom Lane :
>> Robert Haas writes:
>>> On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai wrote:
I tried to reproduce the scenario with enough small
from/join_collapse_limit
(typically 1), but it allows to push down qual
2011/10/19 Tom Lane :
> Robert Haas writes:
>> On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai wrote:
>>> I tried to reproduce the scenario with enough small from/join_collapse_limit
>>> (typically 1), but it allows to push down qualifiers into the least scan
>>> plan.
>
>> Hmm, you're right. LIM
Robert Haas writes:
> On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai wrote:
>> I tried to reproduce the scenario with enough small from/join_collapse_limit
>> (typically 1), but it allows to push down qualifiers into the least scan
>> plan.
> Hmm, you're right. LIMIT 10 prevents qual pu
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai wrote:
> Hi Robert,
>
> I'm a bit confusing about this sentence.
>
>> If you can make this work, I think it could be a pretty sweet plannner
>> optimization even apart from the implications for security views.
>> Consider a query of this form:
>>
>> A
Hi Robert,
I'm a bit confusing about this sentence.
> If you can make this work, I think it could be a pretty sweet plannner
> optimization even apart from the implications for security views.
> Consider a query of this form:
>
> A LEFT JOIN B LEFT JOIN C
>
> where B is a view defined as:
>
> B1
On Mon, Oct 10, 2011 at 4:28 PM, Kohei KaiGai wrote:
> I agreed. We have been on the standpoint that tries to prevent
> leakable functions to reference a portion of join-tree being already
> flatten, however, it has been a tough work.
> It seems to me it is much simple approach that enables to pus
On 10 October 2011 21:28, Kohei KaiGai wrote:
> 2011/10/10 Robert Haas :
>> It seems really ugly to me to suppose that we need to add a depth
>> field to every single one of these node types. If you've missed one,
>> then we have a security hole. If someone else adds another node type
>> later t
On Sun, Oct 09, 2011 at 05:50:52PM +0200, Kohei KaiGai wrote:
> [patch v4]
Each revision of this patch yielded a 1.2 MiB email. Please gzip attachments
this large. The two revisions you sent in September constituted 18% of the
pgsql-hackers bits for the month, and the next-largest message was on
2011/10/10 Robert Haas :
> On Sun, Oct 9, 2011 at 11:50 AM, Kohei KaiGai wrote:
>> I tried to refactor the patches based on the interface of WITH (...)
>> and usage of
>> pg_class.reloptions, although here is no functionality changes; including the
>> behavior when a view is replaced.
>>
>> My pre
On Sun, Oct 9, 2011 at 11:50 AM, Kohei KaiGai wrote:
> I tried to refactor the patches based on the interface of WITH (...)
> and usage of
> pg_class.reloptions, although here is no functionality changes; including the
> behavior when a view is replaced.
>
> My preference is WITH (...) interface,
On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote:
> 2011/10/8 Noah Misch :
> > On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
> >> My preference is still also WITH(security_barrier=...) syntax.
> >>
> >> The arguable point was the behavior when a view is replaced without
2011/10/8 Noah Misch :
> On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
>> My preference is still also WITH(security_barrier=...) syntax.
>>
>> The arguable point was the behavior when a view is replaced without
>> explicit WITH clause;
>> whether we should consider it was specified
On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
> My preference is still also WITH(security_barrier=...) syntax.
>
> The arguable point was the behavior when a view is replaced without
> explicit WITH clause;
> whether we should consider it was specified a default value, or we
> shou
2011/9/30 Noah Misch :
> On Sun, Sep 25, 2011 at 11:22:56PM -0400, Robert Haas wrote:
>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>> > On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>> >> Robert Haas ?09/25/11 10:58 AM >>>
>> >>
>> >> > I'm not sure we've been 100% cons
On Sun, Sep 25, 2011 at 11:22:56PM -0400, Robert Haas wrote:
> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
> > On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
> >> Robert Haas ?09/25/11 10:58 AM >>>
> >>
> >> > I'm not sure we've been 100% consistent about that, since we
>
2011/9/26 Robert Haas :
> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
>> 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
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> One possible idea not to store the flag in RangeTblEntry is to utilize
>> rte->relid to show the relation-id of the source view, when rtekind is
>> RTE_SUBQUERY; that enables to pull the security_barrier flag in
>> executor stage.
>
> Maybe I'm confus
Kohei KaiGai writes:
> One possible idea not to store the flag in RangeTblEntry is to utilize
> rte->relid to show the relation-id of the source view, when rtekind is
> RTE_SUBQUERY; that enables to pull the security_barrier flag in
> executor stage.
Maybe I'm confused here, but what does the exe
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
> 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
>
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> Sorry, are you saying the current (in other words, rte->security_barrier
>> stores the state of reloption) approach is not a good idea?
>
> Yes. I think the same as Robert: the way to handle this is to store it
> in RelOptInfo for the duration of pla
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> However, the interface to reference reloptions are designed to pull
>> this information with Relation pointer, rather than lsyscache, so
>> I implemented this revision with a new rte->security_barrier member.
>
> This approach will guarantee that we c
Kohei KaiGai writes:
> Sorry, are you saying the current (in other words, rte->security_barrier
> stores the state of reloption) approach is not a good idea?
Yes. I think the same as Robert: the way to handle this is to store it
in RelOptInfo for the duration of planning, and pull it from the
ca
Kohei KaiGai writes:
> However, the interface to reference reloptions are designed to pull
> this information with Relation pointer, rather than lsyscache, so
> I implemented this revision with a new rte->security_barrier member.
This approach will guarantee that we can never implement an ALTER V
2011/9/26 Robert Haas :
> On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai wrote:
>>> I think it is. If you create a view that involves an RTE, the node
>>> tree is going to get stored in pg_rewrite.ev_action. And it's going
>>> to include the security_barrier attribute, because you added outfuncs
On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai wrote:
>> I think it is. If you create a view that involves an RTE, the node
>> tree is going to get stored in pg_rewrite.ev_action. And it's going
>> to include the security_barrier attribute, because you added outfuncs
>> support for it...
>>
>> No
On Mon, Sep 26, 2011 at 9:51 AM, Kohei KaiGai wrote:
>> No, you're missing my point completely. If we use a flexible options
>> syntax here, then we have to decide on what behavior CREATE OR REPLACE
>> should have for all future options, without knowing what they are yet,
>> or what behavior will
2011/9/26 Robert Haas :
> On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai wrote:
>> 2011/9/26 Robert Haas :
>>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
> Robert Haas 09/25/11 10:58 AM >>>
>
> > I'm not sur
On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai wrote:
> 2011/9/26 Robert Haas :
>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
Robert Haas 09/25/11 10:58 AM >>>
> I'm not sure we've been 100% consistent abo
2011/9/26 Robert Haas :
> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>>> Robert Haas 09/25/11 10:58 AM >>>
>>>
>>> > I'm not sure we've been 100% consistent about that, since we
>>> > previously made CREATE OR REPLACE LAN
2011/9/26 Robert Haas :
> On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai wrote:
>>> I'm a bit nervous about storing security_barrier in the RTE. What
>>> happens to stored rules if the security_barrier option gets change
>>> later?
>>>
>> The rte->security_barrier is evaluated when a query referen
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>> Robert Haas 09/25/11 10:58 AM >>>
>>
>> > I'm not sure we've been 100% consistent about that, since we
>> > previously made CREATE OR REPLACE LANGUAGE not replace the owner
>>
On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
> Robert Haas 09/25/11 10:58 AM >>>
>
> > I'm not sure we've been 100% consistent about that, since we
> > previously made CREATE OR REPLACE LANGUAGE not replace the owner
> > with the current user.
>
> I think we've been consisten
On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai wrote:
>> I'm a bit nervous about storing security_barrier in the RTE. What
>> happens to stored rules if the security_barrier option gets change
>> later?
>>
> The rte->security_barrier is evaluated when a query referencing security
> views get expan
2011/9/24 Robert Haas :
> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
>> 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 stuff
Robert Haas 09/25/11 10:58 AM >>>
> I'm not sure we've been 100% consistent about that, since we
> previously made CREATE OR REPLACE LANGUAGE not replace the owner
> with the current user.
I think we've been consistent in *not* changing security on an
object when it is replaced.
test=# create
On Sat, Sep 24, 2011 at 5:37 PM, Noah Misch wrote:
> On Fri, Sep 23, 2011 at 06:25:01PM -0400, Robert Haas wrote:
>> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
>> > The Part-1 implements corresponding SQL syntax stuffs which are
>> > "security_barrier"
>> > reloption of views, and "LEAK
On Fri, Sep 23, 2011 at 06:25:01PM -0400, Robert Haas wrote:
> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
> > 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
>
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
> 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.
You have a le
Andrew Dunstan writes:
> On 09/07/2011 12:05 PM, Tom Lane wrote:
>> LEAKPROOF isn't too bad.
> It's fairly opaque unless you know the context, although that might be
> said of some of our other terms too. Someone coming across it is going
> to think "What would it leak?"
Well, the whole point
2011/9/7 Andrew Dunstan :
>> LEAKPROOF isn't too bad.
>>
>>
>
> It's fairly opaque unless you know the context, although that might be said
> of some of our other terms too. Someone coming across it is going to think
> "What would it leak?"
>
It is introduced in the documentation. I'll add a point
On 09/07/2011 12:05 PM, Tom Lane wrote:
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.
Agreed.
LEAKPROOF isn't too bad.
It's fairly opaque unless you know
2011/9/7 Tom Lane :
> Noah Misch 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 c
Noah Misch 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
On Wed, Sep 07, 2011 at 02:09:15PM +0100, Thom Brown wrote:
> On 24 August 2011 13:38, Kohei Kaigai wrote:
>
> > The (2) is new stuff from the revision in commit-fest 1st. It enables to
> > supply "NOLEAKY" option on CREATE FUNCTION statement, then the function is
> > allowed to distribute across
On 2011-09-07 16:02, Kevin Grittner wrote:
Robert Haas wrote:
Anyone else want to bikeshed?
I'm not sure they beat TRUSTED, but:
SECURE
OPAQUE
SAVE
-- Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
2011/9/7 Robert Haas :
> On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown wrote:
>> On 7 September 2011 14:34, Kohei KaiGai wrote:
>>> 2011/9/7 Thom Brown :
>>> > On 24 August 2011 13:38, Kohei Kaigai wrote:
>>> >>
>>> >> The (2) is new stuff from the revision in commit-fest 1st. It enables
>>> >> to
Robert Haas wrote:
> Anyone else want to bikeshed?
I'm not sure they beat TRUSTED, but:
SECURE
OPAQUE
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown wrote:
> On 7 September 2011 14:34, Kohei KaiGai wrote:
>> 2011/9/7 Thom Brown :
>> > On 24 August 2011 13:38, Kohei Kaigai wrote:
>> >>
>> >> The (2) is new stuff from the revision in commit-fest 1st. It enables
>> >> to
>> >> supply "NOLEAKY" option o
On 7 September 2011 14:34, Kohei KaiGai wrote:
> 2011/9/7 Thom Brown :
> > On 24 August 2011 13:38, Kohei Kaigai wrote:
> >>
> >> The (2) is new stuff from the revision in commit-fest 1st. It enables to
> >> supply "NOLEAKY" option on CREATE FUNCTION statement, then the function
> is
> >> allowe
2011/9/7 Thom Brown :
> On 24 August 2011 13:38, Kohei Kaigai wrote:
>>
>> The (2) is new stuff from the revision in commit-fest 1st. It enables to
>> supply "NOLEAKY" option on CREATE FUNCTION statement, then the function is
>> allowed to distribute across security barrier. Only superuser can set
On 24 August 2011 13:38, Kohei Kaigai wrote:
> The (2) is new stuff from the revision in commit-fest 1st. It enables to
> supply "NOLEAKY" option on CREATE FUNCTION statement, then the function is
> allowed to distribute across security barrier. Only superuser can set this
> option.
>
"NOLEAKY"
On Wed, Jul 20, 2011 at 04:23:10PM +0200, Yeb Havinga wrote:
> On 2011-07-20 16:15, Yeb Havinga wrote:
>> On 2011-07-20 16:06, Noah Misch wrote:
>>>
>>> The SQL-level semantics of the view define the access rules in
>>> question. How
>>> would you translate that into tests to apply at a lower le
On 2011-07-20 16:15, Yeb Havinga wrote:
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in
question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not
about
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not about
access rules to views, since it was mention
On Wed, Jul 20, 2011 at 09:02:59AM +0200, Yeb Havinga wrote:
> On 2011-07-09 09:14, Kohei KaiGai wrote:
>> OK, I'll try to modify the patch according to the flag of pg_proc design.
>> As long as the default of user-defined function is off, and we provide
>> built-in functions
>> with appropriate co
2011/7/20 Yeb Havinga :
> On 2011-07-09 09:14, Kohei KaiGai wrote:
>>
>> OK, I'll try to modify the patch according to the flag of pg_proc design.
>> As long as the default of user-defined function is off, and we provide
>> built-in functions
>> with appropriate configurations, it seems to me the b
On 2011-07-09 09:14, Kohei KaiGai wrote:
OK, I'll try to modify the patch according to the flag of pg_proc design.
As long as the default of user-defined function is off, and we provide
built-in functions
with appropriate configurations, it seems to me the burden of DBA is
quite limited.
A diff
On Sat, Jul 09, 2011 at 10:52:33AM +0200, Kohei KaiGai wrote:
> 2011/7/9 Noah Misch :
> > On Sat, Jul 09, 2011 at 09:00:30AM +0200, Kohei KaiGai wrote:
> >> The attached patch is a revised version according to the approach that
> >> updates
> >> pg_class system catalog before AlterTableInternal().
2011/7/9 Noah Misch :
> On Sat, Jul 09, 2011 at 09:00:30AM +0200, Kohei KaiGai wrote:
>> The attached patch is a revised version according to the approach that
>> updates
>> pg_class system catalog before AlterTableInternal().
>> It invokes the new ResetViewOptions when rel->rd_options is not null
On Sat, Jul 09, 2011 at 09:00:30AM +0200, Kohei KaiGai wrote:
> The attached patch is a revised version according to the approach that updates
> pg_class system catalog before AlterTableInternal().
> It invokes the new ResetViewOptions when rel->rd_options is not null, and it
> set
> null on the p
2011/7/9 Robert Haas :
> On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch wrote:
>> Note that it does not matter whether we're actually doing an index scan -- a
>> seq
>> scan with a filter using only leakproof operators is equally acceptable.
>> What I
>> had in mind was to enumerate all operators i
2011/7/8 Noah Misch :
> On Fri, Jul 08, 2011 at 09:20:46AM +0100, Kohei KaiGai wrote:
>> 2011/7/7 Noah Misch :
>> > On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
>> >> 2011/7/7 Noah Misch :
>> >> > On Wed, Jul 06, 2011 at 10:25:12PM +0200, Kohei KaiGai wrote:
>
>> >> > That gets the
On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch wrote:
> Note that it does not matter whether we're actually doing an index scan -- a
> seq
> scan with a filter using only leakproof operators is equally acceptable.
> What I
> had in mind was to enumerate all operators in operator classes of indexes
On Fri, Jul 08, 2011 at 10:09:54AM +0100, Kohei KaiGai wrote:
> 2011/7/8 Heikki Linnakangas :
> > On 08.07.2011 11:03, Kohei KaiGai wrote:
> >>
> >> 2011/7/7 Noah Misch:
> >>>
> >>> Making a distinction based simply on the call being an operator vs. a
> >>> function
> >>> is a dead end. ?I see thes
On Fri, Jul 08, 2011 at 09:20:46AM +0100, Kohei KaiGai wrote:
> 2011/7/7 Noah Misch :
> > On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
> >> 2011/7/7 Noah Misch :
> >> > On Wed, Jul 06, 2011 at 10:25:12PM +0200, Kohei KaiGai wrote:
> >> > That gets the job done for today, but Defin
On Fri, Jul 8, 2011 at 4:18 AM, Heikki Linnakangas
wrote:
> IMHO the situation from DBA's point of view is exactly opposite. Option two
> requires deep knowledge of this leaky views issue. The DBA needs to inspect
> any function he wants to mark as leak-free closely, and understand that
> innocent
1 - 100 of 124 matches
Mail list logo
