Re: replicating DROP commands across servers

On Fri, Oct 3, 2014 at 2:33 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Heikki Linnakangas wrote:
>> On 10/03/2014 09:06 PM, Alvaro Herrera wrote:
>
>> >Well, the return value from get_object_address is an ObjectAddress.
>> >It's simple enough to create an SQL wrapper that takes the
>> >address_names/address_args arrays and return an ObjectAddress; would
>> >this be useful?
>>
>> An ObjectAddress consists of a classid, objid, and objsubid.
>> pg_event_trigger_dropped_objects already returns all of those as
>> separate fields. What am I missing?
>
> Precisely the point is not returning those values, because they are
> useless to identify the equivalent object in a remote database. What we
> need is the object names and other stuff used to uniquely identify it
> "by user-visible name". We transmit those name arrays to a remote
> server, then on the remote server we can run get_object_address and get
> the ObjectAddress, which has the classid,objid,objsubid values you cite ...
> but for the remote server. The object can then be dropped there.
>
> Initially we thought that we would use the object_identity object for
> this (which is why we invented that functionality and added the column
> in 9.3), but this turned out not to work very well for unusual object
> types; hence this patch.

I'm not really very convinced that it's a good idea to expose this
instead of just figuring out a way to parse the object identity.

But I expect to lose that argument.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company