From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: replicating DROP commands across servers |
Date: | 2014-03-28 15:32:37 |
Message-ID: | 20140328153237.GP9567@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-03-28 15:50:10 | pgsql: Fix EquivalenceClass processing for nested append relations. |
Previous Message | Alexander Korotkov | 2014-03-28 15:30:00 | Proposal: fix range queries in btree_gin |