Re: pg_dump and schema names

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump and schema names
Date: 2013-08-09 18:15:31
Message-ID: 20130809181531.GD3353@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 9, 2013 at 01:39:35PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Attachment Content-Type Size
pg_dump.diff text/x-diff 3.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-08-09 18:43:58 Re: confusing error message
Previous Message Tom Lane 2013-08-09 18:11:46 Re: mvcc catalo gsnapshots and TopTransactionContext