On sön, 2011-11-27 at 17:29 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > This ought to show EXECUTE privilege on the new function, but it
> > doesn't, because proacl is null, and nothing in the information schema
> > handles that specially.
>
> > I've pondered some ways to fix that. One would be to add a variant of
> > aclexplode() that takes a parameter telling which catalog the acl datum
> > came from, and aclexplode() could then substitute the data received
> > acldefault() for null values. The other way would be to handle this
> > entirely in the information schema SQL (either using some coalesce calls
> > or perhaps a UNION). But that would mean duplicating the knowledge of
> > acldefault() in a second remote place. So I'm thinking that handling it
> > in aclexplode() would be better.
>
> +1. It would be a really bad idea for the acldefault() logic to be
> duplicated someplace else, especially in SQL code where grepping for the
> relevant macros wouldn't even find it.
I figured the best and most flexible way to address this is to export
acldefault() as an SQL function and replace
aclexplode(proacl)
with
aclexplode(coalesce(proacl, acldefault('f', proowner)))
where 'f' here is something that is mapped to ACL_OBJECT_FUNCTION
internally. AFAICT, there is no existing way to map an SQL-accessible
quantity to the ACL_OBJECT_* symbols, so I'll just have to make
something up.
WIP patch is attached. If there are no objections to this approach,
I'll finish it up.