From: | Joel Jacobson <joel(at)trustly(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Schema version management |
Date: | 2012-07-04 13:02:39 |
Message-ID: | CAASwCXfjw8SUerwoAXRF+g4OsDgP3_XD=6KdxUQfLZR2S-8qhA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut <peter_e(at)gmx(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-07-04 13:26:00 | Re: [ADMIN] pg_basebackup blocking all queries with horrible performance |
Previous Message | Jan Urbański | 2012-07-04 12:11:33 | Re: plpython issue with Win64 (PG 9.2) |