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 !
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
