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

From Tom Lane
Subject Re: pg_dump and schema names
Date
Msg-id 20705.1376069975@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump and schema names  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_dump and schema names  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.

> 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Proposal: leave a hint when switching logging away from stderr
Next
From: Tom Lane
Date:
Subject: Re: mvcc catalo gsnapshots and TopTransactionContext