Re: DROP FUNCTION of multiple functions

Forwarding some comments I neglected to send to the list...

On 1/3/17 9:16 AM, Peter Eisentraut wrote:
> On 1/2/17 1:04 PM, Jim Nasby wrote:
>> On 12/31/16 10:17 AM, Peter Eisentraut wrote:
>>> --- a/src/test/regress/expected/event_trigger.out
>>> +++ b/src/test/regress/expected/event_trigger.out
>>> @@ -80,9 +80,6 @@ create event trigger regress_event_trigger2 on
>>> ddl_command_start
>>> execute procedure test_event_trigger();
>>> -- OK
>>> comment on event trigger regress_event_trigger is 'test comment';
>>> --- should fail, event triggers are not schema objects
>>> -comment on event trigger wrong.regress_event_trigger is 'test comment';
>>> -ERROR: event trigger name cannot be qualified
>>> -- drop as non-superuser should fail
>>>
>>> I'm guessing that's a spurious change...
>>>
>> Well, the test is no longer useful as it was before, because the parser
>> just rejects the command.
>
> Ah. I would have just left it in to make sure a sane error was still
> generated, so I was wondering if something else was going on.

>>> +++ b/src/test/regress/expected/object_address.out
>>> @@ -287,7 +287,7 @@ WARNING: error for function of access
>>> method,{eins,zwei,drei},{integer}: argume
>>> SELECT pg_get_object_address('language', '{one}', '{}');
>>> ERROR: language "one" does not exist
>>> SELECT pg_get_object_address('language', '{one,two}', '{}');
>>> -ERROR: language name cannot be qualified
>>> +ERROR: name list length must be exactly 1
>>>
>>> Arguably, in this usage, that should be array length, not list length.
>>> IIRC there's a function that will map an object type to it's name, so it
>>> wouldn't be hard to restore the previous error message if you wanted to
>>> go that route. pg_get_object_address() has to do a bunch of similar
>>> error checks too, maybe there's a way to combine this stuff.
>>>
>>> It's somewhat unfortunate that
>>> pg_get_object_address()/pg_identify_object_as_address() won't match
>>> these changes, but I don't see any good way to fix that.
>>>
>>> BTW, it would also be damn nice if there was some form of wildcard
>>> available for DROP FUNCTION (and maybe ALTER). If you've created several
>>> overloaded versions of a function, making sure you change all of them
>>> can be a PITA.
>> Yeah, that's the next patch after this. ;-)
>
> Yay :)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)