On Wed, 2002-08-14 at 00:38, Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > On Tue, 2002-08-13 at 22:38, Tom Lane wrote:
> >> It's still "extensible", it's just not so easily "contractible"...
> >>
> >> I'm not sure that this matters, as I've never heard of anyone actually
> >> troubling to remove unused datatypes etc.
>
> > It could become an issue if PostgreSQL became populat in embedded
> > systems, but then it can of course be done in include/catalog/.
>
> For an embedded system I'd think you'd want to strip out the support
> code for the unwanted types (ie, the utils/adt/ file(s)), not only the
> catalog entries. So it's source code changes in any case. The catalog
> entries alone occupy so little space that it's not even worth anyone's
> trouble to remove them, AFAICS.
But if the types themselves were installable, then it would also mean
that unneeded utils/adt/ code would not be installed without need.
> > Probably every type not used in system tables themselves could be made
> > loadable after initdb.
>
> It certainly *could* be done. Whether it's worth the trouble is highly
> doubtful. I'd also be concerned about the performance hit (loadable
> functions are noticeably slower than built-ins).
Really ?
How much is the performance hit ?
Is it unavaoidable ?
Is it the same on all systems ?
Is it the same for both new and old style C functions ?
Is the performance hit only the first time (when function is loaded) or
every time ?
> Again, when was the last time you heard of anyone actually bothering to
> remove built-in entries from pg_proc or pg_type?
I have sometimes removed _my_own_ unused types/functions before shipping
a product ;)
> I can't see expending a considerable amount of work on a "feature" that
> no one will use.
Sure.
-----------
Hannu