On Jan 26, 2005, at 20:06, Pailloncy Jean-Gerard wrote:
I'm glad that some understand that I want to have strong type checking and not multiform filed (with special compound type).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 want that whater is the unit in, the data is coherent. And the output will be format with convert function.
<snip />
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.
This reminds me of Date and Darwen's possible representations. You might be interested in some of their writings, in particular "The Third Manifesto", though they have some papers online as well. Most of what they discuss is at a more theoretical level rather than implementation, but it provides some food for thought. Here's a couple of sites. The second is also includes writings by Fabien Pascal.
http://www.thethirdmanifesto.com/ http://www.dbdebunk.com/index.html
Neat stuff, in my opinion.
Michael Glaesemann grzm myrealbox com
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
