Data type removal

From: Brandon Ibach <bibach(at)infomansol(dot)com>
To: hackers(at)postgresql(dot)org (PostgreSQL Hackers)
Subject: Data type removal
Date: 1998-03-24 12:21:48
Message-ID: 199803241221.GAA09991@vweb.infomansol.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 :)

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1998-03-24 12:53:18 Re: [HACKERS] Data type removal
Previous Message Jose' Soares Da Silva 1998-03-24 11:23:34 Re: [DOCS] Re: [HACKERS] PostgreSQL Reference Guide