Horton

Re: pg_dump --split patch

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: dmitry@koterov.ru, Joel Jacobson <joel@gluefinance.com>, Aidan Van Dyk <aidan@highrise.ca>, Gurjeet Singh <singh.gurjeet@gmail.com>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, David Wilson <david.t.wilson@gmail.com>
Date: 2011-01-23T02:04:33Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_dump: Output functions deterministically sorted

  2. When sorting functions in pg_dump, break ties (same name) by number of arguments

On Mon, Jan 3, 2011 at 2:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jan 3, 2011 at 1:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Yeah, that's exactly it.  I can think of some possible uses for
>>> splitting up pg_dump output, but frankly "to ease diff-ing" is not
>>> one of them.  For that problem, it's nothing but a crude kluge that
>>> only sort-of helps.  If we're to get anywhere on this, we need a
>>> better-defined problem statement that everyone can agree is worth
>>> solving and is well solved with this particular approach.
>
>> I have to admit I'm a bit unsold on the approach as well.  It seems
>> like you could write a short Perl script which would transform a text
>> format dump into the proposed format pretty easily, and if you did
>> that and published the script, then the next poor shmuck who had the
>> same problem could either use the script as-is or hack it up to meet
>> some slightly different set of requirements.  Or maybe you'd be better
>> off basing such a script on the custom or tar format instead, in order
>> to avoid the problem of misidentifying a line beginning with --- as a
>> comment when it's really part of a data item.  Or maybe even writing a
>> whole "schema diff" tool that would take two custom-format dumps as
>> inputs.
>
>> On the other hand, I can certainly think of times when even a pretty
>> dumb implementation of this would have saved me some time.
>
> The basic objection that I have to this patch is that it proposes to
> institutionalize a pretty dumb implementation.  And, as you mentioned,
> once it's in there it'll be more or less set in stone because we aren't
> going to want to support umpteen variants.
>
> I like the idea of a postprocessing script a lot better --- it seems
> like it wouldn't get in the way of people making their own variants.
> And as you say it'd likely be pretty trivial to do.

I notice that this patch is marked as "Needs Review" in the CommitFest
application, but I think it's fair to say that there's no consensus to
commit something along these lines.  Accordingly, I'm going to mark it
"Returned with Feedback".  There is clearly a need for better tooling
in this area, but I think there's a great deal of legitimate doubt
about whether this is the right solution to that problem.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company