Re: Extended unit

>> It strikes me that the right level of constraint is the quantity being
>> represented: length / mass / time / velocity.
>>
>> Then you could store any of: '1inch', '2m', '3km', '4light-years' in a
>> "length" column.
>
> Ofcourse, only one of those is in SI units :) Just like the interval
> type, all this could be handled by the parser. Define some costant
> conversions, after all a light-year is about 9.5e15 metres.
>
> The question is, if you put one inch in, do you expect to get one inch
> out?
I'm glad that some understand that I want to have strong type checking
and not multiform filed (with special compound type).

I want that whater is the unit in, the data is coherent.
And the output will be format with convert function.

If I have a column with "speed DOUBLE(m1s-1)"
I want to be able to put in in any unit format.
If I want special output, I would have a function
doubleunit_to_char(speed,'si') that will output "3 m/s" and
doubleunit_to_char(speed,'si','fr') that will output "3 mètre/seconde"
and
doubleunit_to_char(speed,'si','en') that will output "3 meter/second"
and
doubleunit_to_char(speed,'british','en') that will output "xxx
yard/day" ;-)

I am in the process of writing such function to convert from test to an
internal format.
But the problem is that all the work I am doing is about coupound type
(double, unit)
the unit type is an integer with for table for the definition of unit,
convertion and translation in human form.

Cordialement,
Jean-Gérard Pailloncy