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/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 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
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/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 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
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
24 matches
Mail list logo
