Re: replicating DROP commands across servers
От | Alvaro Herrera |
---|---|
Тема | Re: replicating DROP commands across servers |
Дата | |
Msg-id | 20140328153237.GP9567@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: replicating DROP commands across servers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: replicating DROP commands across servers
|
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > My proposal therefore is to add some more columns to > > pg_event_trigger_dropped_objects(): more precisely, objname and objargs, > > which would carry exactly what get_object_address() would require to > > re-construct an ObjectAddress for the object being dropped at the remote > > end. > > Those aren't strings or indeed flat objects at all, but structures, so it > seems like this is still rather underspecified. How will you represent > something like a List of TypeName at the SQL level? Yeah, that's an ugly case. I'm thinking that I could print those like regtype output would, and then read them back in using (something similar to) parseTypeString(). A bit convoluted perhaps, but I think it should work. For things such as function and cast identities, typmod shouldn't matter AFAIK, so that loss is not significant. Another thing this will need is a table such as static const struct {const char *tm_name;ObjectType tm_type; } ObjectTypeMap[] = {/* relation types */{ "table", OBJECT_TABLE },{ "index", OBJECT_INDEX },{ "sequence", OBJECT_SEQUENCE },... so that we can translate object types back into the ObjectType enum. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: