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/

Wed, 27 Dec 2000 12:41:01 -0500
jmoschet@netscape.net
Re: Permissions on Stored Procedures ==> current_user