From: | PFC <lists(at)boutiquenumerique(dot)com> |
---|---|
To: | "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>, "Pailloncy Jean-Gerard" <jg(at)rilk(dot)com> |
Cc: | "Postgres general mailing list" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Extended unit |
Date: | 2005-01-27 01:42:34 |
Message-ID: | opsk8m08tmth1vuj@musicbox |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> I wonder if it makes sense to implement the units as separate data types
> ? Cause that's what they are really.
> So "amper" would be a data type which aliases one of the numeric data
> types (depending on what precision range you need), but does not allow
> to be added with anything else than "amper". Any other interaction with
> other units (read data types) would be achieved by defining the needed
> operators on the respective data types (read units).
You'd have to create a postgres datatype for every variation on m, m/s,
m/s², etc... which would be kinda unworkable... I think it's better to
have one datatype (number with unit) and have the operators raise an
exception when trying to add incompatible units ?
As for the encoding, why not just use a (float, text) with the text as a
parseable representation of the unit, which could as well be the SI unit
(like m/s) which would be a lot more flexible than bitfields. Problem is I
think it'll always be variable length. Maybe there is enough space in an
int64 to fit it all ? Maybe with huffman coding ? Is it really important
to save a few bytes ? I don't think so.
For table columns, the type would be saved in the column definition so
you'd just have a float anyway.
I think it's an exciting project !
From | Date | Subject | |
---|---|---|---|
Next Message | Mihail Nasedkin | 2005-01-27 03:23:03 | Re: [GENERAL] Lower case |
Previous Message | Jim C. Nasby | 2005-01-27 01:29:29 | Re: difficult JOIN |