On Wed, 21 Aug 2024 at 10:08, jian he <jian.universality@xxxxxxxxx> wrote: > > the following setup is extract from src/test/regress/sql/updatable_views.sql > you can search keywords: "-- ordinary view on top of security invoker > view permissions" > > CREATE TABLE base_tbl(a int, b text, c float); > INSERT INTO base_tbl VALUES (1, 'Row 1', 1.0); > > SET SESSION AUTHORIZATION regress_view_user1; > CREATE VIEW rw_view1 AS SELECT b AS bb, c AS cc, a AS aa FROM base_tbl; > ALTER VIEW rw_view1 SET (security_invoker = true); > > RESET SESSION AUTHORIZATION; > GRANT SELECT(a,b) ON base_tbl TO regress_view_user1; In updatable_views.sql that GRANT is actually GRANT SELECT ON base_tbl TO regress_view_user1; Without that, the view is effectively unusable by regress_view_user1 because it selects from column c of base_tbl, and regress_view_user1 lacks permissions on that column. This is consistent with simple subqueries: select a, b from (select a,b from base_tbl); -- ok a | b ---+------- 1 | Row 1 (1 row) select a, b from (select a,b,c from base_tbl); -- not allowed ERROR: permission denied for table base_tbl The user must have select permissions on all columns selected by the subquery/view, because we don't go through the outer query to check which columns are actually referred to. Now maybe we could, but I suspect that would be quite a lot of effort because you'd need to be sure that the column wasn't referred to anywhere in either the outer query or the subquery itself (e.g., in WHERE clauses, etc.). Regards, Dean
