Re: Extended unit

>> 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 ?
No doable.
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 parseable
I 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