Re: pg_dump --split patch

On Mon, Jan 3, 2011 at 7:11 AM, Dmitry Koterov <dmitry(at)koterov(dot)ru> wrote:
> To me, this is a wonderful feature, thanks! I think many people would be
> happy if this patch woud be included to the mainstream (and it is quite
> short and simple).
> About name ordering - I think that the problem exists for objects:
> 1. Stored functions.
> 2. Foreign keys/triggers (objects which has owning objects).
> It is wonderful that you store all functions with the same name to the same
> file. To order them within this file we may simply compare the first
> definition line lexicographically (or - first line which differs one
> function definition from another).
> Foreign key/triggers ordering problem is described by me at
> http://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg114586.html
> The big problem is with triggers: many triggers may have the same name, but
> be bound to different tables. It would be great to include these triggers to
> table's definition or, at least, have separated files for each trigger+table
> pair.

Hmm... this sounds awfully specific to your particular environment.
My triggers never have the same names... and on the flip side, I
don't see why someone couldn't want one function per file rather than
all same-named functions in one file.

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. We're
going to need to agree on something that won't be perfect for
everyone, but will hopefully be a sufficient improvement for enough
people to be worth doing.

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).

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