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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Proposal: fix range queries in btree_gin
Следующее
От: shamccoy
Дата:
Сообщение: History of WAL_LEVEL (archive vs hot_standby)