After re-reading my original *idea* about using rules to grant access to
stored procedures, I think the better way would be not to implement the code
as stored procedures/functions at all.
Leave that for the more complex low-level add-ons to database functionality .
Using rules and views along with the current_user variable may be cleaner.
(and easier?)
The CREATE_RULE manpage describes this kinda rule that ckecks to see who the
current_user is. I suppose this can also be used in any SQL fashion.
i,e, current_user IN ('a','b','c') Or a subselect. Is there a current_group
variable?
>Deny Joe access to the salary of employees in the shoe department
>(current_user returns the name of the current user):
>
>CREATE RULE example_3 AS
>ON
>SELECT TO emp.salary WHERE old.dept = "shoe" AND current_user = "Joe"
>DO INSTEAD NOTHING;
After some experimenting, is seems that current_user also works with VIEWS
which see to be the way to go for ON SELECT RULES anyway.
So with this it seems safe to say that you can grant access to SQL queries in
Postgres through RULES and VIEWS but this does not seems as robust as actual
functions whose capabilities are nto as limited as code/queries stored in
RULES or VIEW.
Still, does anyone have any comments on adding entries to pg_class for
functions to have ACLs or adding an ACL column to the pg_proc class?
__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at
http://webmail.netscape.com/