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
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 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
---
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
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 +0200, Kohei KaiGai wrote:
That gets the
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
--- 227,257
atcmd-def = (Node *) lfirst(c);
atcmds =
On Thu, Jul 7, 2011 at 10:56 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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
--- 227,257
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 view_name
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 down too far by
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 quals,
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 Sat, Jul 2, 2011 at 1:54 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 2, 2011 at 1:54 PM, Kohei KaiGai kai...@kaigai.gr.jp 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])
On Sat, Jul 2, 2011 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 2, 2011 at 1:54 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
BTW, regarding to the statement support for security barrier views,
the following syntax might be more consistent
On Wed, Jun 29, 2011 at 05:05:22PM +0100, Kohei KaiGai wrote:
2011/6/28 Noah Misch n...@leadboat.com:
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;
2011/6/28 Noah Misch n...@leadboat.com:
On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
2011/6/28 Noah Misch n...@leadboat.com:
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
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
Thanks for your reviewing,
2011/6/28 Noah Misch n...@leadboat.com:
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
On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
2011/6/28 Noah Misch n...@leadboat.com:
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
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
24 matches
Mail list logo
