Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns
Date
Msg-id 20141230221638.GV1645@alvh.no-ip.org
Whole thread Raw
Responses Re: Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Alvaro Herrera wrote:
> pg_event_trigger_dropped_objects: Add name/args output columns
> 
> These columns can be passed to pg_get_object_address() and used to
> reconstruct the dropped objects identities in a remote server containing
> similar objects, so that the drop can be replicated.

This is causing buildfarm member dunlin to fail:

================== pgsql.build/src/test/regress/regression.diffs ===================
*** /buildfarm/root/HEAD/pgsql.build/src/test/regress/expected/privileges.out    Tue Dec 30 13:05:24 2014
--- /buildfarm/root/HEAD/pgsql.build/src/test/regress/results/privileges.out    Tue Dec 30 13:10:49 2014
***************
*** 1323,1328 ****
--- 1323,1329 ----  DROP SCHEMA testns CASCADE; NOTICE:  drop cascades to table testns.acltest1
+ ERROR:  requested object address for object type that cannot support it SELECT d.*     -- check that entries went
away  FROM pg_default_acl d LEFT JOIN pg_namespace n ON defaclnamespace = n.oid   WHERE nspname IS NULL AND
defaclnamespace!= 0;
 

No other member so far has reported a problem here.  Not sure if that's
the strangest bit, or the fact that dunlin is reporting anything in the
first place.  I can reproduce the problem quite simply by creating an
event trigger on sql_drop and then try to drop an object not supported
by getObjectIdentityParts -- in this case it's a default ACL for tables
in the schema being dropped.

My hope was that this check would help us detect new object types that
did not have a working get_object_address representation, but since
there are already cases that don't have it, it's currently bogus.  We
could add the default ACL support without too much effort, I think, but
it would take even less effort to just remove the check.

Another possible option is to mark ALTER DEFAULT PRIVILEGES as an
unsupported command in event triggers.  I'm not sure why we have it,
particularly since we don't have GRANT and REVOKE ... but then my DDL
deparsing patch is supposed to add support for GRANT and REVOKE, so I'm
not really proposing this.

Any strong opinions?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_ctl {start,restart,reload} bad handling of stdout file descriptor
Next
From: Andrew Dunstan
Date:
Subject: Re: [GENERAL] ON_ERROR_ROLLBACK