Re: Schema version management
От | Robert Haas |
---|---|
Тема | Re: Schema version management |
Дата | |
Msg-id | CA+TgmoZRxfYVQ_pM=S_=tMEM355SWgaGPkCMsk24+6FFDpcbuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Schema version management (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: Schema version management
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: