Dennis Bjorklund wrote:
> On Sun, 22 Aug 2004, Peter Eisentraut wrote:
>
>>To me, this seems completely wrong-headed. Data types should be defined
>>by what operations you can do on them, not by what output format they
>>have.
>
> I totally agree, lets get rid of money all together.
>
> If not, what makes money so special? Do we want other numeric types like
> hexnumber, octalnamber, weight, length, ... All of these are different
> ways to format a number in a user interface.
MONEY seems "odd" because it is interpreting its internal
representation based upon locale and the locale is also determining
its possible representation, so one database's MONEY isn't really
the same type as another database's MONEY.
However, Date & Darwen's type model suggests that a database should
have support for types like WEIGHT, LENGTH, and TEMPERATURE,
although they could certainly be left for the user to define. They
define possible representations and THE_ functions as the means to
support multiple units (among other purposes.) For example, a LENGTH
type would have the following selector functions:
LENGTH LENGTH_IN_INCHES(NO_OF_INCHES RATIONAL);
LENGTH LENGTH_IN_FEET(NO_OF_FEET RATIONAL);
LENGTH LENGTH_IN_CM(NO_OF_CM RATIONAL);
Its internal representation would be irrelevant to the user,
although the way PostgreSQL's type extensibility system works, it
would need to have a default unit. It would also have THE_ functions
like:
RATIONAL THE_NO_OF_INCHES(LENGTH);
RATIONAL THE_NO_OF_FEET(LENGTH);
RATIONAL THE_NO_OF_CM(LENGTH);
A DISPLAY() function is invoked to display the type in its default
representation and if one is not defined, an error occurs in D & D's
model. If there must be one, then it would generate unambiguous
output like:
'8.13 inches'
And of course, the various types would be constrained appropriately.
One couldn't have a negative LENGTH or a TEMPERATURE under absolute
zero, as examples. I think it would be neat to have an external
library supporting a large set of types like these.
Mike Mascari
