> 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 !
