On Wed, 2002-08-14 at 00:38, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
