On Wed, Jul 4, 2012 at 9:02 AM, Joel Jacobson <j...@trustly.com> wrote: > On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut <pete...@gmx.net> wrote: >> >> I think this idea has merit. Prepare a patch and put it into the next >> commit fest. > > Glad to hear, I'm on it! > >> >> I see the problem that since the dump order is in general not >> deterministic, this will cause random reordering in your master file >> that includes all the individual files. >> >> >> Then again, making the dump order deterministic is a problem that can be >> solved (I suppose), so maybe starting there would be a good step. But >> it will require a small amount of in-depth pg_dump hacking. > > > I just made a test, where I created objects in different order and compared > the dumps. > It appears pg_dump dumps objects in alphabetically sorted order. > This works fine for most objects, but not for overloaded functions, in which > case > they are dumped in oid order. > > Are there any other cases than overloaded functions, where the dump order > isn't deterministic? > > While waiting for your reply, I'll be working on fixing the problem with > overloaded functions.
My vote is - when there's an overloaded function, put each version in its own file. And name the files something like functionname_something.sql. And just document that something may not be entirely stable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers