Re: Re: [GENERAL] pg_dump behaves differently for different archive formats

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [GENERAL] pg_dump behaves differently for different archive formats
Date: 2014-07-29 16:38:16
Message-ID: 2459.1406651896@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jul 28, 2014 at 10:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If we had something like that, I'd be strongly inclined to get rid of
>> the existing convention whereby comments and ACL commands are separate
>> TOC entries, and make them part of the parent object's TOC entry (which'd
>> mean we'd want to label the sub-strings so we can tell whether they are
>> main object, comment, or ACL). The fewer TOC entries we can have, the
>> better; there is no reason why comments/ACLs should be independently
>> sortable.

> Maybe, but I think people will still want an option to skip restoring
> them altogether (at least for ACLs).

Sure; we already have such an option, and I'm not suggesting removing
it. The implementation would change though: it would have to look at
the individual command labels to see which part(s) of a TOC entry to
print out.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2014-07-29 16:41:05 Re: Problems with pg_upgrade.
Previous Message Robert Haas 2014-07-29 16:35:35 Re: Re: [GENERAL] pg_dump behaves differently for different archive formats

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-07-29 16:51:18 Re: pg_background (and more parallelism infrastructure patches)
Previous Message Marco Nenciarini 2014-07-29 16:35:51 Re: Proposal: Incremental Backup