On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
In case when we try to update / delete a table with inherited
children and RETURNING clause was added, is loses right
references to the pseudo columns, even though it
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
In case when we try to update / delete a table with inherited
children and RETURNING clause was added, is loses right
On 3 December 2012 15:36, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
In case when we try to update / delete a table with inherited
On Mon, Dec 03, 2012 at 03:41:47PM +, Simon Riggs wrote:
On 3 December 2012 15:36, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
David Fetter escribió:
On Mon, Dec 03, 2012 at 03:41:47PM +, Simon Riggs wrote:
On 3 December 2012 15:36, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support
On 15 November 2012 21:07, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a revised version of row-level security
feature.
I've got time to review this patch, so I've added myself as a CF reviewer.
Definitely looks very interesting, well done for getting it this far along.
--
On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Kohei KaiGai escribió:
The revised patch fixes the problem that Daen pointed out.
Robert, would you be able to give this latest version of the patch a
look?
Yeah, sorry I've been completely sidelined this
Robert Haas robertmh...@gmail.com writes:
The documentation lists several documented limitations that I would
like to analyze a little bit. First, it says that row-level security
policies are not applied on UPDATE or DELETE. That sounds downright
dangerous to me. Is there some really
On Mon, Oct 22, 2012 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The documentation lists several documented limitations that I would
like to analyze a little bit. First, it says that row-level security
policies are not applied on UPDATE or DELETE.
2012/10/22 Robert Haas robertmh...@gmail.com:
On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Kohei KaiGai escribió:
The revised patch fixes the problem that Daen pointed out.
Robert, would you be able to give this latest version of the patch a
look?
Yeah,
On Fri, October 19, 2012 11:00, Kohei KaiGai wrote:
I confirmed I could apply the latest patch cleanly.
FWIW, I spent a few sessions (amounting to a few hours) trying to break, or get
past SET ROW LEVEL
SECURITY and have not yet succeeded. So far so good.
(I haven't looked at code)
Erik
Kohei KaiGai escribió:
The revised patch fixes the problem that Daen pointed out.
Robert, would you be able to give this latest version of the patch a
look?
(KaiGai, does it still apply cleanly? If not, please submit a rebased
version.)
--
Álvaro Herrera
On 8 October 2012 15:57, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a refreshed version towards the latest master branch,
to fix up patch conflicts.
Here is no other difference from the previous revision.
Thanks,
I had another look at this over the weekend and I found
2012/10/8 Dean Rasheed dean.a.rash...@gmail.com:
On 8 October 2012 15:57, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a refreshed version towards the latest master branch,
to fix up patch conflicts.
Here is no other difference from the previous revision.
Thanks,
I had
On 17 July 2012 05:02, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/7/17 Robert Haas robertmh...@gmail.com:
On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a revised version of row-level security feature.
...
According to the Robert's comment, I
On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a revised version of row-level security feature.
I added a feature to invalidate plan cache if user-id was switched
between planner and optimizer. It enabled to generate more optimized
plan than the
2012/7/17 Robert Haas robertmh...@gmail.com:
On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a revised version of row-level security feature.
I added a feature to invalidate plan cache if user-id was switched
between planner and optimizer. It
2012/6/28 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
2012/6/27 Florian Pflug f...@phlo.org:
Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
My impression is, here is no matter even if SECURITY DEFINER function
returns refcursor.
I think
2012/6/27 Florian Pflug f...@phlo.org:
On Jun27, 2012, at 15:07 , Kohei KaiGai wrote:
Probably, PlannedStmt-invalItems allows to handle invalidation of
plan-cache without big code changes. I'll try to put a flag of user-id
to track the query plan with RLS assumed, or InvalidOid if no RLS
was
Kohei KaiGai kai...@kaigai.gr.jp writes:
2012/6/27 Florian Pflug f...@phlo.org:
Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
My impression is, here is no matter even if SECURITY DEFINER function
returns refcursor.
I think Florian has a point: it *should* work, but
On Jun28, 2012, at 17:29 , Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
2012/6/27 Florian Pflug f...@phlo.org:
Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
My impression is, here is no matter even if SECURITY DEFINER function
returns refcursor.
I
Florian Pflug f...@phlo.org writes:
On Jun28, 2012, at 17:29 , Tom Lane wrote:
I believe it works today, because the executor only applies permissions
checks during query startup. So those checks are executed while still
within the SECURITY DEFINER context, and should behave as expected.
On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
The problem is the way to implement it.
If we would have permission checks on planner stage, it cannot handle
a case when user-id would be switched prior to executor stage, thus
it needs something remedy to handle the scenario correctly.
Instead
2012/6/27 Florian Pflug f...@phlo.org:
On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
The problem is the way to implement it.
If we would have permission checks on planner stage, it cannot handle
a case when user-id would be switched prior to executor stage, thus
it needs something remedy to
On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug f...@phlo.org wrote:
On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
The problem is the way to implement it.
If we would have permission checks on planner stage, it cannot handle
a case when user-id would be switched prior to executor stage, thus
2012/6/27 Robert Haas robertmh...@gmail.com:
On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug f...@phlo.org wrote:
On Jun27, 2012, at 07:18 , Kohei KaiGai wrote:
The problem is the way to implement it.
If we would have permission checks on planner stage, it cannot handle
a case when user-id
On Jun27, 2012, at 15:07 , Kohei KaiGai wrote:
Probably, PlannedStmt-invalItems allows to handle invalidation of
plan-cache without big code changes. I'll try to put a flag of user-id
to track the query plan with RLS assumed, or InvalidOid if no RLS
was applied in this plan.
I'll investigate
On Thu, Jun 14, 2012 at 11:43 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
In the previous discussion, we planned to add a syntax option to
clarify the command type to fire the RLS policy, such as FOR UPDATE.
But current my opinion is, it is not necessary. For example, we can
reference the
2012/6/26 Robert Haas robertmh...@gmail.com:
Of course, here is some limitations, to keep the patch size reasonable
level to review.
- The permission to bypass RLS policy was under discussion.
If and when we should provide a special permission to bypass RLS
policy, the OR
Kohei KaiGai kai...@kaigai.gr.jp writes:
2012/6/26 Robert Haas robertmh...@gmail.com:
I think you're missing the point. Everyone who has commented on this
issue is in favor of having some check that causes the RLS predicate
*not to get added in the first place*.
Here is a simple idea to
2012/6/26 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp writes:
2012/6/26 Robert Haas robertmh...@gmail.com:
I think you're missing the point. Everyone who has commented on this
issue is in favor of having some check that causes the RLS predicate
*not to get added in the
31 matches
Mail list logo
