No doable.ision 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 ?
After you will need the factorial number of operator between all the combinatory of couple of unit.
As for the encoding, why not just use a (float, text) with the text as a parseableI am doing test with this.
But constraint is done at execution time.
Space is larger.
Operation of two of these is slower than the native one (float).
I want to have it at parsing level to speed the error detection as writing code.
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.(float, text) versus (float)
with text is cd3.A2.sr.m-1.s-2.rad-3.kg-4
with an experiment of few milions of results that have few dozen of parameter.
just to be sure that be not add at parser time meter with second.
I think this work-less, except for a proof of concept.
Cordialement, Jean-Gérard Pailloncy
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@xxxxxxxxxxxxxx)
