Skip site navigation (1) Skip section navigation (2)

Re: pg_dump --split patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: dmitry(at)koterov(dot)ru, Joel Jacobson <joel(at)gluefinance(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>
Subject: Re: pg_dump --split patch
Date: 2011-01-03 18:34:18
Message-ID: 22351.1294079658@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On the specific issue of overloaded functions, I have a feeling that
> the only feasible option is going to be to put them all in the same
> file.  If you put them in different files, the names will either be
> very long (because they'll have to include the argument types) or
> fairly incomprehensible (if you did something like hash the argument
> types and append 8 hex digits to the function name) or not all that
> static (if you use OIDs; or if you number them sequentially, like
> foo1.sql, foo2.sql, foo3.sql, then foo3.sql might end up as foo2.sql
> on a system where there are only two variants of foo, making diff not
> work very well).

If you put all the variants in the same file, diff is *still* not going
to work very well.  At least not unless you solve the problems that keep
pg_dump from dumping objects in a consistent order ... and once you do
that, you don't need this patch.

> I think the problem with this patch is that different people are
> likely to want slightly different things, and there may not be any
> single format that pleases everyone, and supporting too many variants
> will become confusing for users and hard for us to maintain.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-03 18:34:57
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Previous:From: Joel JacobsonDate: 2011-01-03 18:33:39
Subject: Re: pg_dump --split patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group