Re: pg_dump and schema names - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_dump and schema names
Date
Msg-id 20130809181531.GD3353@momjian.us
Whole thread Raw
In response to Re: pg_dump and schema names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump and schema names  (Bruce Momjian <bruce@momjian.us>)
Re: pg_dump and schema names  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Aug  9, 2013 at 01:39:35PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Fri, Aug  9, 2013 at 12:53:20PM -0400, Tom Lane wrote:
> >> This really requires more than no attention to the comments, especially
> >> since you just removed the only apparent reason for _getObjectDescription
> >> to make a distinction between objects whose name includes a schema and
> >> those that don't.
>
> > I am confused.  Are you saying I didn't read the comments, or that I can
> > now merge the schema-qualified and non-schema-qualified object sections?
>
> Well, it's certainly not immediately obvious why we shouldn't merge them.
> But I would have expected the function's header comment to now explain
> that the output is intentionally not schema-qualified and assumes that the
> search path is set for the object's schema if any.

OK, done with the attached patch.  The dump output is unchanged.

> > Also, this seems like dead code as there is no test for "INDEX" in the
> > if() block it exists in:
>
> >         /*
> >          * Pre-7.3 pg_dump would sometimes (not always) put a fmtId'd name
> >          * into te->tag for an index. This check is heuristic, so make its
> >          * scope as narrow as possible.
> >          */
> >         if (AH->version < K_VERS_1_7 &&
> >             te->tag[0] == '"' &&
> >             te->tag[strlen(te->tag) - 1] == '"' &&
> >             strcmp(type, "INDEX") == 0)
> >             appendPQExpBuffer(buf, "%s", te->tag);
> >         else
>
> Huh, yeah it is dead code, since _printTocEntry doesn't call this function
> for "INDEX" objects.  And anyway I doubt anybody still cares about reading
> 7.2-era archive files.  No objection to removing that.

Removed.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: mvcc catalo gsnapshots and TopTransactionContext
Next
From: Stephen Frost
Date:
Subject: Re: confusing error message