Re: Modular Type Libraries: was A real currency type

remove my email from the list

Regards,

-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Andrew Dunstan
Sent: Wednesday, March 22, 2006 9:05 AM
To: tshipley(at)deru(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Modular Type Libraries: was A real currency type

Trent Shipley said:
> 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.

We already have good support of type development. It's not clear to me that
this would buy us anything at all. It seems like modularisation for the sake
of it. The real issue is what types and type mechanisms should be in the
postgresql core distribution. We won't win any thanks from anyone if we
reduce them. Getting some types right is hard. There is no case that I can
see for pushing timestamps, numerics, bitstrings or geometric or network
types out of the core - they need all the support they can get. I'm also not
sure which of these are required by the SQL spec.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org