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 kai...@kaigai.gr.jp:
2012/2/14 Robert Haas robertmh...@gmail.com:
On Tue, Feb
On Wed, Feb 15, 2012 at 6:14 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/2/14 Robert Haas robertmh...@gmail.com:
On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai kai...@kaigai.gr.jp 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,
On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/2/14 Robert Haas robertmh...@gmail.com:
On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Sun, Jan 22, 2012 at 5:12 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/21 Robert Haas robertmh...@gmail.com:
On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I marked the default leakproof function according to the criteria that
does not leak contents of the
On Sun, Jan 22, 2012 at 5:57 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Tue, Jan 17, 2012 at 7:08 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/1/21 Jeff Janes jeff.ja...@gmail.com:
On Tue, Jan 17, 2012 at 7:08 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I guess you concerned about that expected/select_views_1.out is
patched, not expected/select_views.out.
On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Sun, Jan 8, 2012 at 10:52 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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 alternate
On Tue, Jan 3, 2012 at 12:11 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/12/23 Robert Haas robertmh...@gmail.com:
On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'd like the regression test on select_view test being committed also
to detect unexpected changed in
2011/12/23 Robert Haas robertmh...@gmail.com:
On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/12/22 Robert Haas robertmh...@gmail.com:
On Mon, Dec 12, 2011 at 12:00 PM, Kohei KaiGai kai...@kaigai.gr.jp 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.
On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Dec 12, 2011 at 12:00 PM, Kohei KaiGai kai...@kaigai.gr.jp 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.
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 if
2011/12/9 Robert Haas robertmh...@gmail.com:
On Thu, Dec 8, 2011 at 5:17 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Thu, Dec 8, 2011 at 5:17 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/12/8 Robert Haas robertmh...@gmail.com:
On Sat, Dec 3, 2011 at 3:19 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Sep 26, 2011 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp 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
Robert Haas robertmh...@gmail.com 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
On Wed, Dec 7, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Dec 3, 2011 at 3:19 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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 kai...@kaigai.gr.jp:
2011/11/2 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
The reason why I redefined the relid of
On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai kai...@kaigai.gr.jp 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,
2011/11/2 Robert Haas robertmh...@gmail.com:
On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
Kohei KaiGai kai...@kaigai.gr.jp 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
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
On Fri, Oct 21, 2011 at 10:36 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/10/19 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Wed, Oct 19, 2011 at 6:35 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/10/19 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to reproduce the scenario with enough small
Robert Haas robertmh...@gmail.com 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
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai kai...@kaigai.gr.jp 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.
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 JOIN B2
On Sun, Oct 9, 2011 at 11:50 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/10/10 Robert Haas robertmh...@gmail.com:
On Sun, Oct 9, 2011 at 11:50 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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 10 October 2011 21:28, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/10/10 Robert Haas robertmh...@gmail.com:
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
On Mon, Oct 10, 2011 at 4:28 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/10/8 Noah Misch n...@leadboat.com:
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
On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote:
2011/10/8 Noah Misch n...@leadboat.com:
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
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
should
2011/9/30 Noah Misch n...@leadboat.com:
On Sun, Sep 25, 2011 at 11:22:56PM -0400, Robert Haas wrote:
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch n...@leadboat.com 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
On Sun, Sep 25, 2011 at 11:22:56PM -0400, Robert Haas wrote:
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch n...@leadboat.com 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 robertmh...@gmail.com:
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/9/26 Robert Haas robertmh...@gmail.com:
On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/9/26 Robert Haas robertmh...@gmail.com:
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch n...@leadboat.com 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
On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/26 Robert Haas robertmh...@gmail.com:
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch n...@leadboat.com 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
2011/9/26 Robert Haas robertmh...@gmail.com:
On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/26 Robert Haas robertmh...@gmail.com:
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch n...@leadboat.com wrote:
On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner
On Mon, Sep 26, 2011 at 9:51 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2011/9/26 Robert Haas robertmh...@gmail.com:
On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
Kohei KaiGai kai...@kaigai.gr.jp 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
Kohei KaiGai kai...@kaigai.gr.jp 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
2011/9/26 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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
2011/9/26 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
Kohei KaiGai kai...@kaigai.gr.jp 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
2011/9/26 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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
On Sat, Sep 24, 2011 at 5:37 PM, Noah Misch n...@leadboat.com 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 kai...@kaigai.gr.jp wrote:
The Part-1 implements corresponding SQL syntax stuffs which are
security_barrier
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 user
2011/9/24 Robert Haas robertmh...@gmail.com:
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
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 consistent in *not*
On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch n...@leadboat.com 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 Fri, Sep 23, 2011 at 06:25:01PM -0400, Robert Haas wrote:
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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.
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com 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
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com 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
On 7 September 2011 14:34, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in commit-fest 1st. It enables to
supply NOLEAKY option on CREATE FUNCTION
On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown t...@linux.com wrote:
On 7 September 2011 14:34, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in
Robert Haas robertmh...@gmail.com 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
2011/9/7 Robert Haas robertmh...@gmail.com:
On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown t...@linux.com wrote:
On 7 September 2011 14:34, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The
On 2011-09-07 16:02, Kevin Grittner wrote:
Robert Haasrobertmh...@gmail.com 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:
On Wed, Sep 07, 2011 at 02:09:15PM +0100, Thom Brown wrote:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com 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
Noah Misch n...@leadboat.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
2011/9/7 Tom Lane t...@sss.pgh.pa.us:
Noah Misch n...@leadboat.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
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
2011/9/7 Andrew Dunstan and...@dunslane.net:
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
Andrew Dunstan and...@dunslane.net 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
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
2011/7/20 Yeb Havinga yebhavi...@gmail.com:
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
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
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
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 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 level?
I
2011/7/8 Noah Misch n...@2ndquadrant.com:
On Fri, Jul 08, 2011 at 09:20:46AM +0100, Kohei KaiGai wrote:
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Wed, Jul 06, 2011 at 10:25:12PM
2011/7/9 Robert Haas robertmh...@gmail.com:
On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch n...@2ndquadrant.com 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
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
2011/7/9 Noah Misch n...@2ndquadrant.com:
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
On Sat, Jul 09, 2011 at 10:52:33AM +0200, Kohei KaiGai wrote:
2011/7/9 Noah Misch n...@2ndquadrant.com:
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
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Sun, Jul 03, 2011 at 11:41:47AM +0200, Kohei KaiGai wrote:
The simplified version of fix-leaky-view patch. The part of reloptions
for views got splitted out
into the part-0 patch, so it needs to be applied prior to this patch.
Rest of logic to
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Mischn...@2ndquadrant.com:
Making a distinction based simply on the call being an operator vs. a function
is a dead end. I see these options:
1. The user defining a security view can be assumed to trust the operator class
members of
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Wed, Jul 06, 2011 at 10:25:12PM +0200, Kohei KaiGai wrote:
*** a/src/backend/commands/view.c
--- b/src/backend/commands/view.c
---
2011/7/8 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Mischn...@2ndquadrant.com:
Making a distinction based simply on the call being an operator vs. a
function
is a dead end. I see these options:
1. The user defining a
1 - 100 of 124 matches
Mail list logo
