2012/5/31 Kohei KaiGai kai...@kaigai.gr.jp:
2012/5/31 Robert Haas robertmh...@gmail.com:
If we would have an ideal optimizer, I'd still like the optimizer to
wipe out redundant clauses transparently, rather than RLSBYPASS
permissions, because it just controls all-or-nothing stuff.
For example
2012/5/29 Robert Haas robertmh...@gmail.com:
On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I think it is a good idea not to apply RLS when current user has
superuser privilege from perspective of security model consistency,
but it is inconsistent to check privileges
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the current ExecCheckRTEPerms()
always raises an error towards unprivileged users, prior
2012/5/28 Florian Pflug f...@phlo.org:
On May28, 2012, at 02:46 , Noah Misch wrote:
On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
Since the security barrier flag carries a potentially hefty performance
penalty, I think it should be optional. Application which don't allow
2012/5/29 Florian Pflug f...@phlo.org:
On May29, 2012, at 13:59 , Kohei KaiGai wrote:
2012/5/28 Florian Pflug f...@phlo.org:
Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
by the security_barrier flag. However, as you pointed out, it's a bit of a
dubious concept
2012/5/29 Florian Pflug f...@phlo.org:
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables
2012/5/29 Robert Haas robertmh...@gmail.com:
One idea might be to have a grantable permission that permits the RLS
policy to be bypassed. So, if a user has only SELECT permission, they
can select from the table, but the RLS policy will apply. If they
have both SELECT and RLSBYPASS (probably
2012/5/24 Robert Haas robertmh...@gmail.com:
On Thu, May 24, 2012 at 6:11 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Perhaps when we see that RLS
applies, we should replace the reference to the original table with a
subquery RTE that has the security_barrier flag set - essentially
treating
2012/5/24 Robert Haas robertmh...@gmail.com:
On Thu, May 24, 2012 at 12:00 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Another issue, BTW, are FOREIGN KEY constraints. Should you be allowed to
created references to rows which are invisible to you, or should FOREIGN KEY
constraints be exempt
2012/5/25 Florian Pflug f...@phlo.org:
On May24, 2012, at 19:25 , Robert Haas wrote:
FWIW, I'm inclined to think that you should NOT be able to create a
row that references an invisible row. You might end up with that
situation anyway, because we don't know what the semantics of the
security
2012/5/23 Robert Haas robertmh...@gmail.com:
On Wed, May 23, 2012 at 3:45 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I wanted to have discussion to handle this problem.
Unlike leaky-view problem, we don't need to worry about unexpected
qualifier distribution on either side of join, because
2012/5/24 Florian Pflug f...@phlo.org:
If we also apply the security policy to newer version of tuples on
update and insert, one idea is to inject a before-row-(update|insert)
trigger to check whether it satisfies the security policy.
For same reason, the trigger should be executed at the end
2012/5/24 Florian Pflug f...@phlo.org:
On May24, 2012, at 12:43 , Kohei KaiGai wrote:
The case of INSERT / DELETE are simple; All we need to apply is
checks on either new or old tuples.
In case of UPDATE, we need to check on the old tuple whether use can
see, and on the new tuple whether use
2012/5/24 Florian Pflug f...@phlo.org:
On May24, 2012, at 16:19 , Kohei KaiGai wrote:
So, the proposed interface might be revised as follows:
ALTER TABLE tblname ADD SECURITY POLICY
func_name(args, ...) [FOR SELECT |
INSERT
on child table.
Any comments please. Thanks,
2012/5/24 Kohei KaiGai kai...@kaigai.gr.jp:
2012/5/24 Florian Pflug f...@phlo.org:
On May24, 2012, at 16:19 , Kohei KaiGai wrote:
So, the proposed interface might be revised as follows:
ALTER TABLE tblname ADD SECURITY POLICY
func_name(args
Let me have a discussion to get preferable interface for row-level security.
My planned feature will perform to append additional conditions to WHERE
clause implicitly, to restrict tuples being visible for the current user.
For example, when row-level policy uname = getpgusername() is configured
2012/5/23 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Let me have a discussion to get preferable interface for row-level security.
My planned feature will perform to append additional conditions to WHERE
clause implicitly, to restrict tuples being visible
2012/5/23 Alastair Turner b...@ctrlf5.co.za:
On Wed, May 23, 2012 at 5:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Let me have a discussion to get preferable interface for row-level security.
My planned feature will perform to append additional conditions
2012/3/10 Simon Riggs si...@2ndquadrant.com:
On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan and...@dunslane.net wrote:
On 03/09/2012 01:40 PM, Robert Haas wrote:
On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheelerda...@justatheory.com
wrote:
On Mar 9, 2012, at 7:55 AM, Merlin Moncure
2012/3/20 Robert Haas robertmh...@gmail.com:
On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga yebhavi...@gmail.com wrote:
In the patch with copy-editing documentation following that commit, at in
at their option, s/in// ?
Oh, yeah. Oops. Thanks.
Also 'rather than .. as mandated by the
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Suppose that the connection starts out in context connection_pooler_t.
Based on the identity of the user, we transition to foo_t, bar_t, or
baz_t. If it's possible, by any
2012/3/9 Robert Haas robertmh...@gmail.com:
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
[ new patch ]
Are we absolutely certain that we want the semantics of
sepgsql_setcon() to be transactional? Because if we made them
non-transactional, this would be a whole
2012/3/11 Yeb Havinga yebhavi...@gmail.com:
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with added
documentation.
Thanks for your dedicated volunteer. I'm under checking of the updates
at
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a practical reason. In case when httpd open the connection to PG and
set a suitable security label according to the given credential prior to
launch
of user
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a practical reason. In case when httpd open
2012/3/6 Alvaro Herrera alvhe...@commandprompt.com:
It seems to me that the only thing that needs core support is the
ability to start up the daemon when postmaster is ready to accept
queries, and shut the daemon down when postmaster kills backends (either
because one crashed, or because it's
value.
Most of comments update are quite helpful for me.
So, I merged your revised one in this patch.
Thanks so much!
2012/3/3 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-24 17:25, Yeb Havinga wrote:
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havingayebhavi...@gmail.com:
On 2012
2012年2月28日12:00 Shigeru Hanada shigeru.han...@gmail.com:
(2012/02/28 18:08), Thom Brown wrote:
If that's something that will likely be introduced in future, then
surely we'd want to keep the tableoid column rather than removing it
then re-introducing it later?
As background knowledge,
2012/2/24 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-24 15:17, Yeb Havinga wrote:
I don't know what's fishy about the mgrid user and root that causes
c0.c1023 to be absent.
more info:
In shells started in a x environment under Xvnc, id -Z shows the system_u
and c0.c1023 absent.
In
2012/2/24 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havingayebhavi...@gmail.com:
So maybe this is because my start domain is not s0-s0:c0.c1023
However, when trying to run bash or psql in domain
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0
2012/2/20 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to label.c
because of references to static variables. The part-2 patch implements above
mechanism.
I took a short look at this patch but am
2012年2月17日6:08 Shigeru Hanada shigeru.han...@gmail.com:
(2012/02/17 2:02), Kohei KaiGai wrote:
I found a strange behavior with v10. Is it available to reproduce?
snip
I tried to raise an error on remote side.
postgres=# select * FROM ftbl WHERE 100 / (a - 3) 0;
The connection
for the review. Attached patches are revised version, though
only fdw_helper_v5.patch is unchanged.
(2012/02/16 0:09), Kohei KaiGai wrote:
[memory context of tuple store]
It calls tuplestore_begin_heap() under the memory context of
festate-scan_cxt at pgsqlBeginForeignScan.
Yes, it's because tuplestore
2012年2月16日13:41 Shigeru Hanada shigeru.han...@gmail.com:
Kaigai-san,
Thanks for the review. Attached patches are revised version, though
only fdw_helper_v5.patch is unchanged.
(2012/02/16 0:09), Kohei KaiGai wrote:
[memory context of tuple store]
It calls tuplestore_begin_heap() under
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
Harada-san,
I checked the v9 patch, however, it still has some uncertain implementation.
[memory context of tuple store]
It calls tuplestore_begin_heap() under the memory context of
festate-scan_cxt at pgsqlBeginForeignScan.
On the other hand, tuplestore_gettupleslot() is called under the
memory
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
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
2012/2/13 Greg Smith g...@2ndquadrant.com:
On 02/11/2012 08:14 PM, Gaetano Mendola wrote:
The trend is to have server capable of running CUDA providing GPU via
external hardware (PCI Express interface with PCI Express switches), look
for example at PowerEdge C410x PCIe Expansion Chassis from
2012年2月1日12:15 Shigeru Hanada shigeru.han...@gmail.com:
(2012/01/30 4:39), Kohei KaiGai wrote:
I checked the fdw_helper_funcs_v3.patch, pgsql_fdw_v5.patch and
pgsql_fdw_pushdown_v1.patch. My comments are below.
Thanks for the review!
[BUG]
Even though pgsql_fdw tries to push-down
2012/1/28 Kohei KaiGai kai...@kaigai.gr.jp:
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can
Hi Harada-san,
I checked the fdw_helper_funcs_v3.patch, pgsql_fdw_v5.patch and
pgsql_fdw_pushdown_v1.patch. My comments are below.
[BUG]
Even though pgsql_fdw tries to push-down qualifiers being executable
on the remove side at the deparseSql(), it does not remove qualifiers
being pushed down
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It seems to me reasonable design.
The attached patch is rebased one according to your perform-deletion patch.
That looks pretty sensible. But I don't think this is true any
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that. I think. But if you expose a
2012/1/23 Simon Riggs si...@2ndquadrant.com:
On Sun, Jan 22, 2012 at 3:48 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to implement a fdw module that is designed to utilize GPU
devices to execute
qualifiers of sequential-scan on foreign tables managed by this module.
It was named PG
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
Hi,
I tried to implement a fdw module that is designed to utilize GPU
devices to execute
qualifiers of sequential-scan on foreign tables managed by this module.
It was named PG-Strom, and the following wikipage gives a brief
overview of this module.
http://wiki.postgresql.org/wiki/PGStrom
2012/1/23 Robert Haas robertmh...@gmail.com:
On Sun, Jan 22, 2012 at 10:48 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to implement a fdw module that is designed to utilize GPU
devices to execute
qualifiers of sequential-scan on foreign tables managed by this module.
It was named PG
2012/1/19 Robert Haas robertmh...@gmail.com:
On Thu, Jan 19, 2012 at 3:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/19 Robert Haas robertmh...@gmail.com:
On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
In sepgsql side, it determines a case to apply permission
2012/1/19 Robert Haas robertmh...@gmail.com:
On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
In sepgsql side, it determines a case to apply permission checks
according to the contextual information; that is same technique
when we implemented create permission.
Thus
2012/1/17 Robert Haas robertmh...@gmail.com:
On Tue, Jan 10, 2012 at 7:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch adds OAT_DROP object-access-hook around permission
checks of object deletion.
Due to the previous drop statement reworks, the number of places to
put
This patch adds a new GUC sepgsql.client_label that allows client
process to switch its privileges into another one, as long as the
system security policy admits this transition.
Because of this feature, I ported two permissions from process class
of SELinux; setcurrent and dyntransition. The
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
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
-in estimators side,
and we should enforce estimator function being leakproof, even though
we still allow unprivileged users to define operators.
Thanks,
2011/12/11 Kohei KaiGai kai...@kaigai.gr.jp:
2011/12/10 Kohei KaiGai kai...@kaigai.gr.jp:
2011/12/9 Robert Haas robertmh...@gmail.com:
I feel like
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
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
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
2011/12/3 Robert Haas robertmh...@gmail.com:
On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
At least, it is working. However, it is not a perfect solution to the
future updates
of code paths in the core.
Hmm. So, do you want this committed? If so, I think the major
;
default:
/* internal calls */
return;
}
:
}
At least, it is working. However, it is not a perfect solution to the
future updates
of code paths in the core.
Thanks,
2011/11/29 Kohei KaiGai kai...@kaigai.gr.jp:
2011/11/28 Dimitri Fontaine dimi
2011/11/30 Robert Haas robertmh...@gmail.com:
On Sun, Nov 27, 2011 at 3:14 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
If we add new properties that required by AlterObjectNamespace, as
you suggested, it will allow to reduce number of caller of this routine
mechanically with small changes
2011/11/28 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
I found up a similar idea that acquires control on ProcessUtility_hook and
save necessary contextual information on auto variable then kicks the
original ProcessUtility_hook, then it reference
2011/11/27 Dimitri Fontaine dimi...@2ndquadrant.fr:
And, it seems to me the current proposition of the command trigger
does not support to fire triggers on creation of databases, although
permission checks requires Oid of source database that is not also
appeared in pg_database catalog.
I
2011/11/28 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
How does it inherit an opaque private initialized at BEFORE trigger to
AFTER trigger? I checked your patch, however, it seems to me it does
not have a mechanism to deliver something between BEFORE
2011/11/26 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
We still don't have clear direction of the way to implement external
permission
checks on object creation time. So, please consider these patches are on the
proof-of-concept stage; using prep
2011/11/21 Robert Haas robertmh...@gmail.com:
Now, what you have here is a much broader reworking. And that's not
necessarily bad, but at the moment I'm not really seeing how it
benefits us.
In my point, if individual object types need to have its own handler for
alter commands, points of
2011/11/27 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
I wonder if you could implement that as an extension given the command
trigger patch finds its way in. What do you think?
Unfortunately, it does not solve my point.
[...]
It is also reason why I
Hanada-san,
I'm still under reviewing of your patch, so the comment is not overall, sorry.
I'm not sure whether the logic of is_foreign_expr() is appropriate.
It checks oid of the function within FuncExpr and OpExpr to disallow to push
down user-defined functions.
However, if a user-defined
2011/11/18 Robert Haas robertmh...@gmail.com:
On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Part-2) Groundworks on objectaddress.c
This patch adds necessary groundworks for Part-3 and Part-4.
It adds ObjectPropertyType of objectaddress.c index-oid and cache-id
Thanks for your reviewing.
The reason of this strange message was bug is the patch.
CREATE TABLE public.copy1(a, b) AS SELECT * FROM public.test;
ERROR: whole-row update is not implemented
When it constructs a fake RangeTblEntry, it marked modifiedCols for
attribute 0 to (tupdesc-natts - 1),
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
2011/10/21 Robert Haas robertmh...@gmail.com:
On Fri, Oct 21, 2011 at 12:44 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I had checked my older implementation based on 8.4.x or 9.0.x that
includes all the features that I want to implement.
At least, it does not require so much different
2011/11/1 Robert Haas robertmh...@gmail.com:
On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to summarize permission checks of DAC/MAC on several object classes
that are allowed to assign security label right now.
http://wiki.postgresql.org/index.php?title
2011/10/26 Robert Haas robertmh...@gmail.com:
2011/10/26 Shigeru Hanada shigeru.han...@gmail.com:
(2011/10/25 19:15), Magnus Hagander wrote:
2011/10/25 Shigeru Hanadashigeru.han...@gmail.com:
I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
contrib module. I think that
ATM I'm not sure it's even a good idea to push pgsql_fdw into contrib.
Once we do that its release schedule will get locked to core's ---
wouldn't it be better to keep flexibility for now, while it's in such
active development?
I would be happy to keep it outside, and integrate it in the
2011/10/20 Robert Haas robertmh...@gmail.com:
On Thu, Oct 20, 2011 at 10:49 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
part-3: drop statement reworks for other object classes
This is going to need some rebasing.
OK, I rebased it.
This patch includes bug-fix when we tried to drop non
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
How about the current status of this patch, although it is still
Waiting on author.
If Hanada-san would propose contrib/pgsql_fdw as a basis of join-pushdown
feature, I'll likely volunteer to review the patch.
I'm also interested in this feature. Hopefully, I'd like to try other
kind of pushing
When someone comes along in another year or two and adds materialized
views, will they need to pass some additional data to the object
access hook? Probably, but I bet you're the only one who can quickly
figure out what it is. That's no good. We're not going to make
changes to PostgreSQL
2011/10/18 Robert Haas robertmh...@gmail.com:
In the example table creation, heap_create_with_catalog() is invoked
by 5 routines, however, 3 of them are just internal usages, so it is not
preferable to apply permission checks on table creation
Some wit once made the remark that if a
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
2011/10/18 Robert Haas robertmh...@gmail.com:
On Thu, Oct 13, 2011 at 6:48 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
struct ObjectAccessInfoData {
ObjectAccessType oa_type;
ObjectAddress oa_address;
union {
struct {
HeapTuple
2011/10/18 Robert Haas robertmh...@gmail.com:
On Tue, Oct 18, 2011 at 11:25 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
For example, I hope sepgsql to perform as follows when user create a new
table.
- It computes a default security label that needs Oid of the namespace.
- It checks db_table
3. Add the notion of a leakproof function, which can benefit from the
optimization of #1 even when the view involved is a security view as
introduced in #2
Thanks,
2011/10/11 Robert Haas robertmh...@gmail.com:
On Mon, Oct 10, 2011 at 4:28 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I agreed
to
pull up from InsertPgClassTuple.
Thanks,
2011/10/12 Robert Haas robertmh...@gmail.com:
On Thu, Sep 29, 2011 at 4:52 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I noticed that the previous revision does not provide any way to inform
the modules name of foreign server, even if foreign table
I noticed a problem of get_object_address() with missing_ok = true.
When we try to solve the name of nonexistent rule/trigger/constraint on
a particular existing table, get_object_address_relobject() opens the
relation, but address.objectId = InvalidOid shall be set.
I think it should be closed
, without this patch.
Thanks,
2011/10/13 Kohei KaiGai kai...@kaigai.gr.jp:
I noticed a problem of get_object_address() with missing_ok = true.
When we try to solve the name of nonexistent rule/trigger/constraint on
a particular existing table, get_object_address_relobject() opens the
relation
to translattions with
opposite direction.)
Thanks,
2011/10/11 Robert Haas robertmh...@gmail.com:
On Mon, Oct 10, 2011 at 1:38 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'm sorry again. I tought it was obvious from the filenames.
I guess I got confused because you re-posted part 2 without
2011/10/12 Robert Haas robertmh...@gmail.com:
On Wed, Oct 12, 2011 at 8:07 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'm currently trying to revise my patches according to your suggestions,
but I'm facing a trouble about error messages when user tries to drop
a non-exists object.
Because
2011/10/10 Robert Haas robertmh...@gmail.com:
On Wed, Oct 5, 2011 at 2:58 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Hmm. It indeed makes translation hard.
I reverted this portion of the part-2 patch, as attached.
Please review the newer one, instead of the previous revision.
Please fix
OK, well, I applied pgsql-v9.2-drop-reworks-2.v4.1.patch and tried to
compile, and got this:
In file included from ../../../src/include/catalog/dependency.h:17,
from dependency.c:19:
../../../src/include/catalog/objectaddress.h:21: warning: type
defaults to ‘int’ in
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
. However, the planner gives
higher priority on the join plan between
local and foreign than pushing-down foreign relations.
Does it make sense not to consider any other possible plans when FDW
decided a particular join can be
pushed down?
Thanks,
2011年10月7日18:06 Kohei KaiGai kai...@kaigai.gr.jp
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
2011年10月4日12:08 Shigeru Hanada shigeru.han...@gmail.com:
In my opinion, FdwRoutine should have an additional API to inform the core
its
supported features; such as inner-join, outer-join, order-by,
group-by, aggregate
functions, insert, update, delete, etc... in the future version.
Sure,
Thanks for your reviewing.
2011/10/4 Robert Haas robertmh...@gmail.com:
On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I rebased the patches towards the latest git master, so I believe these
are available to apply.
Reviewing away...
I don't see why we need one
Hanada-san,
I applied your patch and run a few test cases. while this test, I
noticed a few points.
At first, I tried to use file_fdw, however, it was crashed of course.
It seems to me this logic should be modified to confirm whether the target FDW
support join push down, or not.
+ if
at the security topic.
If someone volunteers to review this patch from the different viewpoint, not
only security features, it is quite helpful for us.
Thanks,
2011/9/29 Kohei KaiGai kai...@kaigai.gr.jp:
I noticed that the previous revision does not provide any way to inform
the modules name of foreign
301 - 400 of 521 matches
Mail list logo
