The attached patch is a revised one; that utilizes untransformRelOptions()
to construct a list of DefElem to be supplied into AT_ResetRelOptions
commands. It enabled me to implement more compact as I expected.
How about this approach to reset existing reloptions?
I'll consolidate part-0, 1 and 2
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 these options:
>>>
>>> 1. The user defining a security view can be assumed to trus
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:
>> >> *** a/src/backend/commands/view.c
>> >> --- b/src/backend/commands/view.c
>> >
>> >> --- 227,257
>> >>
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 these options:
1. The user defining a security view can be assumed to trust the operator class
members of indexes defined on the tab
2011/7/7 Noah Misch :
> 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 prevent unexpect
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 prevent unexpected pushing down across secur
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:
> >> *** a/src/backend/commands/view.c
> >> --- b/src/backend/commands/view.c
> >
> >> --- 227,257
> >> atcmd->d
On Thu, Jul 7, 2011 at 10:56 AM, Kohei KaiGai wrote:
> My opinion is ALTER TABLE SET/RESET code should be enhanced to accept
> an operation to reset all the existing options, rather than tricky
> updates of pg_class.
> How about an idea to add AT_ResetAllRelOptions for internal use only?
>
> I'll
2011/7/7 Noah Misch :
> 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
>
>> --- 227,257
>> atcmd->def = (Node *) lfirst(c);
>> atcmds = lappend(a
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
> --- 227,257
> atcmd->def = (Node *) lfirst(c);
> atcmds = lappend(atcmds, atcmd);
>
On Sun, Jul 03, 2011 at 11:33:38AM +0200, Kohei KaiGai wrote:
> The attached patches are revised version.
>
> The part-0 provides 'security_barrier' option for view definition, and
> performs
> as a common basis of part-1 and part-2 patches.
> Syntax is extended as follows:
>
> CREATE VIEW vie
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 prevent unexpected pushing down across security
barrier is not changed.
Thanks,
2011/6/6 Kohei Kaigai :
> This p
On Sat, Jul 2, 2011 at 3:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jul 2, 2011 at 1:54 PM, Kohei KaiGai wrote:
>>> BTW, regarding to the statement support for security barrier views,
>>> the following syntax might be more consistent with existing ones:
>>> CREATE VIEW view_name WI
Robert Haas writes:
> On Sat, Jul 2, 2011 at 1:54 PM, Kohei KaiGai wrote:
>> BTW, regarding to the statement support for security barrier views,
>> the following syntax might be more consistent with existing ones:
>> CREATE VIEW view_name WITH ( param [=value]) AS query ... ;
>> rather than
>>
On Sat, Jul 2, 2011 at 1:54 PM, Kohei KaiGai wrote:
> BTW, regarding to the statement support for security barrier views,
> the following syntax might be more consistent with existing ones:
> CREATE VIEW view_name WITH ( param [=value]) AS query ... ;
> rather than
> CREATE SECURITY VIEW view_na
BTW, regarding to the statement support for security barrier views,
the following syntax might be more consistent with existing ones:
CREATE VIEW view_name WITH ( param [=value]) AS query ... ;
rather than
CREATE SECURITY VIEW view_name AS query ...;
Any comments?
2011/7/2 Noah Misch :
> On S
On Sat, Jul 02, 2011 at 12:48:32PM +0200, Kohei KaiGai wrote:
> > Let's see. ?Every qual list will have some depth d such that all quals
> > having
> > depth >= d are security-relevant, and all others are not security-relevant.
> > (This does not hold for all means of identifying security-relevant
>> > I was referring to this paragraph:
>> >
>> > ?On the technical side, I am pretty doubtful that the approach of adding a
>> > ?nestlevel to FuncExpr and RelOptInfo is the right way to go. ?I believe we
>> > ?have existing code (to handle left joins) that prevents quals from being
>> > ?pushed d
On Wed, Jun 29, 2011 at 05:05:22PM +0100, Kohei KaiGai wrote:
> 2011/6/28 Noah Misch :
> > On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
> > CREATE VIEW a AS SELECT * FROM ta WHERE ac = 5;
> > ALTER VIEW a OWNER TO alice;
> > CREATE VIEW b AS SELECT * FROM tb WHERE bc = 6;
> > ALTE
2011/6/28 Noah Misch :
> On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
>> 2011/6/28 Noah Misch :
>> > Suppose your query references two views owned by different roles. ?The
>> > quals
>> > of those views will have the same depth. ?Is there a way for information to
>> > leak from on
On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
> 2011/6/28 Noah Misch :
> > Suppose your query references two views owned by different roles. ?The quals
> > of those views will have the same depth. ?Is there a way for information to
> > leak from one view owner to another due to that
Thanks for your reviewing,
2011/6/28 Noah Misch :
> I took a look at this patch. It's incredibly simple, which is great, and it
> seems to achieve its goal.
>
> Suppose your query references two views owned by different roles. The quals
> of those views will have the same depth. Is there a way
I took a look at this patch. It's incredibly simple, which is great, and it
seems to achieve its goal.
Suppose your query references two views owned by different roles. The quals
of those views will have the same depth. Is there a way for information to
leak from one view owner to another due t
This patch enables to fix up leaky-view problem using functions with tiny cost
estimation scenario.
The point of this scenario is criteria to reorder qualifiers of scanning plan
in order_qual_clauses(). The optimizer may pull up simple subqueries into upper
level, then its qualifier will get me
101 - 124 of 124 matches
Mail list logo
