Re: pgsql: Add regression test for bug fixed by recent refactoring. - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Add regression test for bug fixed by recent refactoring.
Date
Msg-id 18583.1367374482@sss.pgh.pa.us
Whole thread Raw
In response to pgsql: Add regression test for bug fixed by recent refactoring.  (Kevin Grittner <kgrittn@postgresql.org>)
Responses Re: pgsql: Add regression test for bug fixed by recent refactoring.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Kevin Grittner <kgrittn@postgresql.org> writes:
> Add regression test for bug fixed by recent refactoring.
> Test case by Andres Freund for bug fixed by Tom Lane's refactoring
> in commit 5194024d72f33fb209e10f9ab0ada7cc67df45b7

Hm, that actually has got nothing much to do with matviews:

regression=# create view vv1 as select false;
CREATE VIEW
regression=# create view vv2 as select false where false;
CREATE VIEW
regression=# create user joe;
CREATE ROLE
regression=# \c - joe
You are now connected to database "regression" as user "joe".
regression=> select * from vv1;
ERROR:  permission denied for relation vv1
regression=> select * from vv2;
 bool
------
(0 rows)

Of course the select from vv2 should fail as well, but it doesn't,
because vv2 is nowhere to be seen in the rangetable passed to the
executor.  I think the planner is probably trashing the rangetable
once it realizes that the query is completely dummy; but this is wrong
because we need to leave view rangetable entries behind for permissions
checks, even when they're unreferenced in the finished plan.

            regards, tom lane


pgsql-committers by date:

Previous
From: Kevin Grittner
Date:
Subject: pgsql: Add regression test for bug fixed by recent refactoring.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Add regression test for bug fixed by recent refactoring.