Re: Schema version management
От | Andrew Dunstan |
---|---|
Тема | Re: Schema version management |
Дата | |
Msg-id | CAD5tBcKOSQ+TvibcMXjAoBo5M_J0E08hZQSq1-25MFx7C6c=Nw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Schema version management (Gurjeet Singh <singh.gurjeet@gmail.com>) |
Ответы |
Re: Schema version management
Re: Schema version management |
Список | pgsql-hackers |
On Thu, Jul 5, 2012 at 4:04 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
No they are not necessarily one logical unit. You could have a bunch of functions called, say, "equal" which have pretty much nothing to do with each other, since they refer to different types.
+1 from me for putting one function definition per file.
cheers
andrew
I think there's a merit to keeping all overloaded variations of a function in a single file, apart from the simplicity and benefits noted above. A change in one variation of the function may also be applicable to other variations, say in bug-fixes or enhancements. So keeping all variations in one file would make sense, since it is logically one object.On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson <joel@trustly.com> wrote:On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:its own file. And name the files something likeMy vote is - when there's an overloaded function, put each version in
functionname_something.sql. And just document that something may not
be entirely stable.I would agree that's better if the dump order isn't deterministic.However, it looks like an easy fix to make the dump order deterministic:If the dump order is deterministic, I think its cleaner to put all versions in the same file.Benefits:+ Pretty looking filename+ Same file structure for all object types, no special exception for functions
No they are not necessarily one logical unit. You could have a bunch of functions called, say, "equal" which have pretty much nothing to do with each other, since they refer to different types.
+1 from me for putting one function definition per file.
cheers
andrew
В списке pgsql-hackers по дате отправления: