Without directly addressing the merits of enumerations, enumeration
interfaces, real currency and time zone types, or whether currency and time
zone types should be built using enumerations, I would like to ask the
powers-that-be to seriously consider radically modularizing Postgresql's type
system.
The core Postgresql installation would come with just those built-in types
needed to bootstrap itself, perhaps just varchar and an integer type.
Everything else would be a contributed module.
An interface or contract would be described for creating additional types. It
would include things like parameter handlers, how to dump the type, and how
to load the type. (That is, standard housekeeping functions needed by the
Postgresql engine.)
Other that the tiny number of bootstrap types, Postgresql types would
basically all be contrib modules.
Types could be bundled into groups such as binary, character, numerical,
2d-spatial, networking, and so on.
Then one would not debate whether a type (or meta-type, like an enumeration)
should be put into the core product. Instead, the debate would be whether or
not to grade the type as "mature" and whether or not to put a given type into
pre-packaged type libraries with names like "legacy", "sql-2003-standard", or
"recommended-default".
Power user DBA's could customize the types offered on their systems.
In short:
1) Types would be modular. This would be elegant, but have no practical
effect on database performance.
2) The framework needed to support modular types would encourage type
development. This would enhance Postgresql's adaptability which would be A
Very Good Thing.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
