Re: Extended unit - Mailing list pgsql-general

From Csaba Nagy
Subject Re: Extended unit
Date
Msg-id 1106741911.19443.101.camel@localhost.localdomain
Whole thread Raw
In response to Re: Extended unit  (Pailloncy Jean-Gerard <jg@rilk.com>)
Responses Re: Extended unit
List pgsql-general
Hi all,

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).

And all the "unit" stuff could be added as an extension.

Is this a workable solution ?

Cheers,
Csaba.

On Wed, 2005-01-26 at 12:06, Pailloncy Jean-Gerard wrote:
> >> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly


pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Extended unit
Next
From: "Raymond O'Donnell"
Date:
Subject: Re: EMBEDDED PostgreSQL