Re: Issue with GRANT/COMMENT ON FUNCTION with default

From: Jim Nasby <jim(at)nasby(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issue with GRANT/COMMENT ON FUNCTION with default
Date: 2014-05-07 18:08:24
Message-ID: DF8A167B-3561-46D4-BC37-17B581DE89A9@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/5/14, 3:22 PM, Alvaro Herrera wrote:
> Jim Nasby wrote:
>> Prior to default parameters on functions, GRANT and COMMENT accepted full parameter syntax. IE:
>>
>> GRANT EXECUTE ON test(t text) TO public
>>
>> as opposed to regprocedure, which only accepts the data types ( test(text), not test(t text) ).
>>
>> They do not accept DEFAULT though:
>>
>> GRANT EXECUTE ON FUNCTION test(t text DEFAULT '') to public;
>> ERROR: syntax error at or near "DEFAULT"
>> LINE 1: GRANT EXECUTE ON FUNCTION test(t text DEFAULT '') to public;
>>
>> Presumably this is just an oversight?
>
> I have to say that accepting DEFAULT there seems pretty odd to me. What
> if you specify the wrong default? Do you get a "no such function"
> error? That would be pretty unhelpful. But then accepting it ignoring
> the fact that the default is wrong would be rather strange.

We already have that exact problem with the name of the argument.

decibel(at)decina(dot)cashnetusa=# CREATE FUNCTION test(t text default '') RETURNS text LANGUAGE sql AS 'SELECT $1';
CREATE FUNCTION
decibel(at)decina(dot)cashnetusa=# GRANT EXECUTE ON FUNCTION test(baz text) to public;
GRANT
decibel(at)decina(dot)cashnetusa=#

>> Related to that, is it intentional that the regprocedure cast
>> disallows *any* decorators to the function, other than type? If
>> regprocedure at least accepted the full function parameter definition
>> you could use it to get a definitive reference to a function.
>
> Does pg_identify_object() give you what you want?

No, because I'd need an OID, and I have no way of reliably getting that because the regprocedure cast won't even accept additional information beyond data type.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-05-07 18:13:14 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous Message Josh Berkus 2014-05-07 18:04:48 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers