On Fri, Oct 3, 2014 at 2:33 PM, Alvaro Herrera <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
