From: | "Harald Massa" <HaraldMassa(at)ghum(dot)de> |
---|---|
To: | "Marc Munro" <marc(at)bloodnok(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: row based security ... was Different views with same name for |
Date: | 2002-01-21 21:47:18 |
Message-ID: | 017301c1a2c5$3c1bb3b0$0100a8c0@tog2 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Marc,
thank you very much for this idea.
> create view x as
> select *
> from t_x
> where i_can_see(name);
i had this function "can_see(bid)", and the can_see function checked for the
name.
It works.
BUT: this method kills the query-planner. seq_scan is chosen no matter what.
Today I used a simplified idea out of the earlier responses
create table useracc (uname text, bid int4);
insert into useracc values ('ham', 234);
insert into useracc values ('ham', 548);
(234 and 548 and... are the ids of a special field (like areacode) in the
database)
and the view
create view pers as select persganz join useracc on
persganz.berater=useracc.bid
and useracc.uname=current_user;
an
explain select persganz join useracc on persganz.berater=useracc.bid
and useracc.uname=current_user;
shows, that the index on persganz.berater is used... and useracc is
sequencially scanned (THAT is fine, because it is very very short)
but...
update
and
insert
are still painfull...
Thank you for your thoughts!
STILL I believe, that this kind of abstraction SHOULD exist on database
level... because it is a VERY common problem. Or isn't it?
By
HArald
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-21 22:04:11 | Re: row based security ... was Different views with same |
Previous Message | Bruce Momjian | 2002-01-21 21:40:56 | Re: [HACKERS] PostgreSQL Licence: GNU/GPL |