Re: Rules, Triggers something more challenging - Mailing list pgsql-general

From Dennis Gearon
Subject Re: Rules, Triggers something more challenging
Date
Msg-id 3E8C70FD.7010900@cvc.net
Whole thread Raw
In response to Rules, Triggers something more challenging  ("Peter Csaba" <cpeter@webnova.ro>)
List pgsql-general
Haven't you asked tihs question already? :-) I keep seeing what to me is the
exact same question with no replies in the question. And I remember replying to
it, and seeing replies to it.

did any of the answers work?

Peter Csaba wrote:
> Hello,
>
> I have the following problem. I have a database with different tables.
> This database is accessed from different users using different logins to
> access some of the tables.
> It's not a problem to limit the access of these users to certain tables.
> They can be included into a group and allowed access based on group granting
> to tables.
>
> My problem is to set these users to be able to access (SELECT| MODIFY|
> UPDATE) some rows
> from a given table based on some information from the given row.
>
>
> For example:
> We have various locations (discos) where people are visitors. These
> locations store the visitors into a table.
>
> Table:
>
> CREATE TABLE "visitors" (
>   "visitor_id" SERIAL,
>   "login" text,
>   "password" text,
>   "disco_id" int4
> );
>
> Each disco (location) is accessing the database with their own login (ie:
> disco1, disco2).
> Each disco has a disco_id. It is linked to the login which the disco uses to
> access the database.
> For one login more than one disco_id can be assigned, so with a given login
> several disco_id accesses are allowed.
>
>
> For this I set up a permission table where we have:
>
> create table permissions (
>          disco_id int4,
>          username name not null
> );
> here we have for example:
>  35    disco1
>  40    disco1
>  44    disco2
>
> Users logged in with "disco1" should be able to INSERT, SELECT, MODIFY data
> from the visitors table where the disco_id is 35 or 40 in our example.
>
>
> Let's hide the visitors table from there users and let them think that we
> use besucher table to store these visitors data.
>
> For this I  define a view:
>
> create view besucher as
>          select v.* from visitors v, permissions  P
>         where  v.disco_id=P.disco_id
>         AND P.username =  CURRENT_USER;
>
>
> So  if I log in as user "disco1" and enter:
> select * from besucher;                        then I get only user from
> disco 35 and 40.
>
> This is good. SELECT IS SOLVED.
>
>
>
> Now if I set a RULE like:
>
> create  rule visitors_del as ON DELETE TO besucher
>         DO  INSTEAD  DELETE FROM visitors WHERE
>         visitor_id=OLD.visitor_id
>         AND  permissions.username = CURRENT_USER
>         AND  visitors.disco_id=permissions.disco_id;
>
> This allows  me to not to be able to delete just the visitors belonging to
> disco  35 and 40.
>
> So:
> delete from visitors; - would  only delete the users belonging to disco 35,
> 40. So far this is  ok aswell.
>
> The problem is that I can't  create rules for insert and update.
> For insert I wanted  to set up something like:
>
> create rule visitors_ins as  ON INSERT TO besucher
>         WHERE  NEW.disco_id!=permissions.disco_id
>         AND permissions.username =  CURRENT_USER
>         DO INSTEAD  NOTHING;
>
> So if I want to insert a row where disco_id is not available in the
> permissions table to the current user - just skip it, do nothing.
> Unfortunately this  rule cannot be created the way I wrote above.
>
> Can anybody tell me how this can be realized or to give some better
> solutions ideas?
>
> The ideea is, to not to allow users who logged in with user "disco1" for
> example to access
> data othen than they are allowed to access in the permissions table.
>
>
> Best regards,
> Peter Csaba
> Director General
> WebNova Romania
> www.webnova.ro
> www.muresinfo.ro
>
> str. Bradului nr. 8
> Tg.-Mures, 4300, Romania
> Tel: +40-265-162417
> Mobile: +40-722-505295
>
> -----------------------------------------------------------------
> ATTENTION:
> No legal consequences can be derived from the content of this
> e-mail and/or its attachments. Neither is sender committed to
> these. The content of this e-mail is exclusively intended for
> addressee(s) and information purposes. Should you receive this
> message by mistake, you are hereby notified that any disclosure,
> reproduction, distribution or use of this message is strictly
> prohibited. Sender accepts no liability for any damage resulting
> from the use and/or acceptation of the content of this e-mail.
> Always scan attachments for viruses before opening them.
> -----------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>


pgsql-general by date:

Previous
From: "Delao, Darryl W"
Date:
Subject: Postgres Syslog
Next
From: "Ferindo Middleton Jr"
Date:
Subject: config file, where is it