Alvaro Herrera wrote:
> 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.
The other thing to keep in mind is that with all those ObjectAddress
thingies you got, you cannot simply construct a DROP <obj> command:
1. The objects in the list might be of different types; say a table and
a view that are dropped by the same command because of CASCADE. (You
could just pass the CASCADE to the other side and hope that it happens
to do the same thing; but if the schemas are slightly different, it
might not.)
2. DROP OWNED or other commands might have dropped several objects,
again of varying types.
So what we do in BDR is stuff all those ObjectAddress in an array of
them, and then call performMultipleDeletions. There is no way to get
this functionality in non-C code; so it's hard to see that it's very
useful to have a non-C way to use the original objnames/objargs arrays.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services