On Mon, 17 Nov 2014 14:56:13 +0100
Christoph Berg <m...@debian.org> wrote:
Hi,
> I don't think that's a bug. While it's uncommon for builtin functions
> to have named arguments, there's a few others in pg_catalog.
>
> Also, GRANT/REVOKE works with named parameters as well:
>
> CREATE FUNCTION exec(text) RETURNS text LANGUAGE plpgsql VOLATILE AS
> $f$BEGIN EXECUTE $1; RETURN $1; END;$f$;
>
> select exec(format('grant all on function %I(%s) to public', proname,
> pg_get_function_arguments(oid))) from pg_proc where proname ~ 'uuid';
> exec
> -----------------------------------------------------------------------------
> [...] grant all on function uuid_generate_v3(namespace uuid, name
> text) to public grant all on function uuid_generate_v4() to public
> grant all on function uuid_generate_v5(namespace uuid, name text) to
> public (22 Zeilen)
ahemmmmm, not a very usual way to do so… (at least for me).
> What issue specifically do you have with this?
In fact, I didn't knew your way to grant/revoke rights on functions
(and I do not remember having seen that in any of Pg docs); it is
also when trying to recover user's privileges that it breaks badly.
I use a query to retrieve all functions from a schema (stolen from
psql intrinsics \dn?), then I issue a classic:
SELECT has_function_privilege(user, fun, priv);
which fails is any argument has a name.
Anyway, the presence of this extension was due to former tests, so I
solved this issue by removing it and tagged my program incompatible
with it.
Jean-Yves
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
