Re: row based security ... was Different views with same name for
От | Harald Massa |
---|---|
Тема | Re: row based security ... was Different views with same name for |
Дата | |
Msg-id | 017301c1a2c5$3c1bb3b0$0100a8c0@tog2 обсуждение исходный текст |
Ответ на | Re: row based security ... was Different views with same name for (Marc Munro <marc@bloodnok.com>) |
Ответы |
Re: row based security ... was Different views with same
|
Список | 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
В списке pgsql-general по дате отправления: