Re: row based security ... was Different views with same name for

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

In response to

Responses

Browse pgsql-general by date

  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