On Wed, Jul 4, 2012 at 9:02 AM, Joel Jacobson <joel@trustly.com> wrote:
> On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut <peter_e@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
