Re: replicating DROP commands across servers

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replicating DROP commands across servers
Date: 2014-10-03 20:49:57
Message-ID: 20141003204956.GI7043@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost wrote:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > Right. In the "add to objname" cases, there is already some other
> > routine that initialized it previously by filling in some stuff; in the
> > case above, this happens in the getRelationIdentity() immediately
> > preceding this.
> >
> > In the other cases we initialize on that spot.
>
> ahh, ok, that makes a bit more sense, sorry for missing it. Still makes
> me wonder why objargs gets special treatment at the top of the function
> and objnames doesn't- seems like both should be initialized either
> before being passed in (and perhaps an Assert to verify that they are),
> or they should both be initialized, but I tend to prefer just Assert'ing
> that they are correct on entry- either both are valid pointers to empty
> lists, or both NULL.

I guess I could initialize objnames to NIL also. I initialize objargs
because that one is unused for a lot of object types (so I would have to
set it to NIL in cases where it's not used), whereas objnames is always
used and thus we know it's always initialized later.

Maybe what I need here is just a longer comment explaining this ...

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-10-03 20:53:00 Re: replicating DROP commands across servers
Previous Message Robert Haas 2014-10-03 20:47:38 Re: [RFC] Incremental backup v2: add backup profile to base backup