From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Guillaume Bog <guibog(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: pl/pgsql RECORD data type, how to access to the values |
Date: | 2008-04-06 17:56:32 |
Message-ID: | 47F90ED0.3030008@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Guillaume Bog wrote:
> I want a table to be "read-only", so I raise exceptions with a before
> trigger on update, insert and delete. It works well.
>
> This read-only table is modified (delete + insert) by a trigger
> function set on another table, but this second trigger calls the first
> and I can modify my read-only table. I'd like my "read-only" trigger
> to be aware that the modification call on the read-only table comes
> from the second trigger. Is it possible?
Quick question: Why not make the read only table a view of the writeable
table, instead of using triggers to copy data?
If your data doesn't fit that use or that'd be inefficient, can you use
access privileges rather than a trigger to limit changes to the read
only table? I find that limiting a user to SELECT priveleges on a table
and using a SECURITY DEFINER trigger or other function to perform
certain restricted priveleged operations on the table to be very useful.
In your case you might be able to restrict users to SELECT priveleges on
your read only table, drop the "read only" restriction trigger, and make
the updating trigger SECURITY DEFINER (after carefully thinking about
possible risks and issues).
Why the separate read only table, anyway? A materialized view / summary
table? Something to do with user access control ?
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-04-06 17:59:01 | Re: slow pgsql tables - need to vacuum? |
Previous Message | Craig Ringer | 2008-04-06 17:49:15 | Re: slow pgsql tables - need to vacuum? |