I, for one, am in favor of converting some of the type packages to
loadable modules. Having those in the backend when they aren't being
used is much like compiling extra modules into my Apache web server
because they're "kinda neat", even though they won't be used. Also,
if we follow the idea that we should have as many unique features in
the backend as possible, we could end up with all sorts of features
that are only used by a subset of users. For instance, I don't use
the geometric types, but I do use a soundex type which I created. Why
isn't the soundex type a standard part of the backend? I, personally,
am glad it's not, because I like the version of this type that I
created a lot better than the one that's in contrib.
As far as the whole performance-improvement issue, I can say that
if the backend is, say, 50K smaller due to the removal of those
functions, that's just that much less swapping and that much more
memory that's available for the OS buffer cache. Isn't that an
improvement worth considering?
How about this as a compromise. We make these packages available
in the contrib or other such area as loadable modules as well as
making them available right in the main backend code, but setup
configure options to enable/disable them, so when I compile, I can say
"--without-geometry" to compile without those types and functions. If
I want to add them back in later, I can compile the loadable module
version and add them in.
-Brandon :)
