Re: pg_dump --split patch

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