2011/1/3 Robert Haas <robertmhaas@gmail.com>:
> will become confusing for users and hard for us to maintain. We're
> going to need to agree on something that won't be perfect for
> everyone, but will hopefully be a sufficient improvement for enough
> people to be worth doing.
Good point.
I think we can at least agree the "bare minimum" is splitting per
namespace, object type and name.
> On the specific issue of overloaded functions, I have a feeling that
> the only feasible option is going to be to put them all in the same
> file. If you put them in different files, the names will either be
> very long (because they'll have to include the argument types) or
> fairly incomprehensible (if you did something like hash the argument
> types and append 8 hex digits to the function name) or not all that
> static (if you use OIDs; or if you number them sequentially, like
> foo1.sql, foo2.sql, foo3.sql, then foo3.sql might end up as foo2.sql
> on a system where there are only two variants of foo, making diff not
> work very well).
I agree.
Even if the overloaded functions are not written in the same order,
you will quickly and easily note "function(s) of this particular name
has been changed", which should narrow down your
mind-mapping-change-grasping-exercise quite a lot.
--
Best regards,
Joel Jacobson
Glue Finance