Re: Schema version management - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Schema version management
Date
Msg-id CAD5tBcKOSQ+TvibcMXjAoBo5M_J0E08hZQSq1-25MFx7C6c=Nw@mail.gmail.com
Whole thread Raw
In response to Re: Schema version management  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Responses Re: Schema version management  (Michael Glaesemann <grzm@seespotcode.net>)
Re: Schema version management  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers


On Thu, Jul 5, 2012 at 4:04 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
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:
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.

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

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.


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 by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: [PATCH] pg_dump: Sort overloaded functions in deterministic order
Next
From: Michael Glaesemann
Date:
Subject: Re: Schema version management