When a new function is created, the initial default EXECUTE privilege is
granted to PUBLIC (this is described is the documentation), and pgAdmin
generates the followng script:
CREATE OR REPLACE FUNCTION ... ;
ALTER FUNCTION ... OWNER TO ...;
The function's ACL is dispayed in the 'ACL' field in the object properties
upper-right pane and in this case it is null. (As far as I can guess the
contents are just read from the 'proacl' field of the 'pg_proc' system
catalog table.)
If then to revoke all privileges both from PUBLIC and the owner, this
function would be accessible only to a superuser, and its ACL property is
'{}' (empty). Empty and null values are different, and this behavior is by
design. But the script generated in the SQL pane remains the same.
In any case there should be no problem for a pgAdmin user to determine the
effective ACL of a function by examining its ACL in the property list. But
let's observe the problem from the top point of view. Deciding to take
advantage of using a DDL script carefully prepared by pgAdmin, one might
expect that creating an object in another schema/database from the scratch
executing this script he gets the exact copy of the object including the
correct ACL.
To implement this in case of empty, but not null, ACL of functions (and
other database objects granting default access to PUBLIC), the
reverse-engineering procedure of pgAdmin might be modified for the script to
look like:
CREATE OR REPLACE FUNCTION ... ;
ALTER FUNCTION ... OWNER TO <owner>;
REVOKE ALL ON FUNCTION ... FROM public;
REVOKE ALL ON FUNCTION ... FROM <owner>;
Regards,
Dmitry.
