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
    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!
855-TREBLE2 (855-873-2532)

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to