Peter Eisentraut wrote:
Kyle writes: > Peter Eisentraut wrote:
>
> > Kyle writes:
> >
> > > Is there a way to get this to work without granting update to table b?
> >
> > Update to 7.1.]
>
> I'm on 7.1. Should an RI trigger under 7.1 run as the DBA or as the current
> user?
Okay, we missed a few cases. Try the attached patch.
OK, here's another similar one. Should this work? (sorry there's really a little more here than you absolutely need, but it demonstrates the problem)
drop view atab_v1;
drop view atab_v2;
drop view atab_v3;
drop view atab_v4;
drop table atab;
drop function func_atab ();
drop function func_v1 ();
drop function func_v2 ();
create table atab (
f1 int4
);
insert into atab (f1) values (1);
insert into atab (f1) values (2);
insert into atab (f1) values (3);
create view atab_v1 as select * from atab;
create view atab_v2 as select * from atab;
create function func_atab () returns numeric as '
select sum(f1) from atab;
' language 'sql';
create function func_v1 () returns numeric as '
select sum(f1) from atab_v1;
' language 'sql';
create function func_v2 () returns numeric as '
select sum(f1) from atab_v2;
' language 'sql';
create view atab_v3 as select *,func_v1() from atab_v2;
create view atab_v4 as select *,func_atab() from atab_v2;
grant select on atab_v2 to kyle;
grant select on atab_v3 to kyle;
grant select on atab_v4 to kyle;
Now as user Kyle, try to select from atab_v3 or atab_v4. Both give permission denied because no explicit permission is given to the view/table underlying the summing function.
Shouldn't the select access to the view trickle down to subordinate select functions?
Kyle
