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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
