Thanks Craig.
I still find it a bit awkward that we have to use "priv check function"-s
because we can't define triggers on or reference to system tables. I think
that allowing it would significantly extend Postgres possibilities.
From a quick google it seems that triggers on system tables is allowed in
MySQL.
So, all this just leaves me wondering why this is not possible in Postgres.
Regards,
Davor
"Craig Ringer" <craig@postnewspapers.com.au> wrote in message
news:4C313581.2060506@postnewspapers.com.au...
> On 04/07/10 21:43, Davor J. wrote:
>
>
>> PS using inheritance in this scenario is problematic.
>
> Yep. Just one issue is that roles are cluster-wide, whereas tables are
> visible only inside a single database.
>
> I generally use the role mechanism as-is, granting users access to roles
> that control particular privileges. Especially now that Pg has column
> privileges I rarely even need to use triggers to check for role
> membership - the standard permissions model is increasingly sufficient.
>
> If it's not for you, you could always maintain a table of additional
> privilege information that new roles with default privileges are added
> to when a priv check function first "sees" them. With a (say) daily pass
> to remove entries associated with roles that no longer exist, that
> should be fine. It's not as nice as using a proper inheritance/extension
> mechanism, but it leaves you a lot safer from changes caused by
> PostgreSQL upgrades.
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>