Thread

Compilation problems and extension on Windows

Shachar Shemesh <psql@shemesh.biz> — 2004-08-22T11:09:38Z

Hi list,

I asked both these questions on the cygwin list, but as I've started to 
look into the native port as well, and as I didn't get any answer there, 
I would appreciate any answer here as well.

I'm trying to compile an external library for use as a postgres 
extension. The project is available on pgfoundry (search for mssqlext). 
On Unix everything works great. On Windows, I'm trying for both a cygwin 
and a native version of the extension. I'm having several problems:
1. I cannot link the library without postgres.exe (that has several of 
the functions I need). However, I do not have access to the link library 
for it.
2. I have downloaded both the sources from the web and the sources 
available in the cygwin installer. They are not the same. Neither 
compiles on cygwin, however.
3. I have not located any instructions for compiling the native sources 
(8.0 beta 1). The makefiles available through the sources only compile 
libpq and psql and friends, not the actual database. I have not tried 
MSYS yet, but do I just run the configure script as usual?

Any help with any of these problems would be greatly appretiated.

             Shachar

-- 
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/

monetary bug

Mahmoud Taghizadeh <m_taghi@yahoo.com> — 2004-08-22T11:50:33Z

I found a little bug in monetary function of
postgresql function cash_in in file cash.c
the problem is that when I run 
set lc_monetary to "fa_IR.UTF8"
and try to insert a value to a field with type of
money, I got the following error:
"invalid input syntax for type money: "1000"

at the same time when I run "set lc_monetary to
"en_US.UTF8", everythings worked well.

I studied the source code and I found that cash.c has
a little problem to handling money type. I found that
this bug exists for all of countries that have not
precision for their money. 

I decided to write a patch for this bug, but before I
start my work, i want to know if anyone has any idea
about this bug or not?

a dirty method to fix this bug is to replace following
line 
if (isdigit((unsigned char) *s) && dec < fpoint )
with 
if (isdigit((unsigned char) *s) && ((dec < fpoint) ||
fpoint == 0))


M, Taghizade
Regards

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

NLS support for postgreSQL

Mahmoud Taghizadeh <m_taghi@yahoo.com> — 2004-08-22T11:53:54Z

Dear All,

we are envolving in a national project and we want to
add our locale support in postgreSQL. we found that
the postgreSQL does not support locale very well. we
want to start our work by translation some part of
postgreSQL documents. then fix some little bug about
our locale in postgreSQL and our main target is adding
locale support per column.
 
1. we want to translate some postgreSql documents
(FAQ, tutorial for start). I want to know who is
responsible for this part in postgreSQL (we are from
IRAN)
 
2. there is a little bug about our monetary in
postgreSQL (locale), if I want to fix it who is
responsible to contact with him.
 
3. we are planning to add locale per column for
postgreSQL, but I found that you had said its
impossible.  am I right? do you have any paper about
it?
 
4. If I want to add collate order for postgreSQL what
should I do? is there any guideline for adding this
feature in postgreSQL
 
Please dont  us alone in this project, we need your
help and guidlines.
 
I am thankful in advance.
Regards

=====
With Regards,
--taghi


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: NLS support for postgreSQL

Peter Eisentraut <peter_e@gmx.net> — 2004-08-22T12:31:36Z

Mahmoud Taghizadeh wrote:
> 1. we want to translate some postgreSql documents
> (FAQ, tutorial for start). I want to know who is
> responsible for this part in postgreSQL (we are from
> IRAN)

You are. :)

> 2. there is a little bug about our monetary in
> postgreSQL (locale), if I want to fix it who is
> responsible to contact with him.

This list.

> 3. we are planning to add locale per column for
> postgreSQL, but I found that you had said its
> impossible.  am I right? do you have any paper about
> it?

It's possible, but difficult.

> 4. If I want to add collate order for postgreSQL what
> should I do? is there any guideline for adding this
> feature in postgreSQL

Collation order support needs to be provided by the operating system 
locales.  I think Farsi should be supported.  If in doubt, read the 
documentation.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: NLS support for postgreSQL

Dennis Björklund <db@zigo.dhs.org> — 2004-08-22T12:40:25Z

On Sun, 22 Aug 2004, Mahmoud Taghizadeh wrote:

> 3. we are planning to add locale per column for
> postgreSQL, but I found that you had said its
> impossible.  am I right? do you have any paper about
> it?
>  
> 4. If I want to add collate order for postgreSQL what
> should I do? is there any guideline for adding this
> feature in postgreSQL

Impossible is way to strong word. It's just a lot of work.

Encoding and collation order should be per column (is there any more local
information needed then collation order?). In fact, each string handled
inside pg need such information stored. It's similar to a type of an
object, and can probably be handled in a similar way.

What I suggest is that you first check out the sql specification (already
sql92 includes this) and whatever solution made should support what's in
the standard (or at least be as close as possible). We don't just want to
code up something that works somewhat and that later makes it hard to do
the right thing demanded by the standard. I'm not saying that one have to
do everything that's in the standard, just that what we do should not
break the standard in arbitrary ways.

-- 
/Dennis Björklund

Re: monetary bug

Tom Lane <tgl@sss.pgh.pa.us> — 2004-08-22T17:29:14Z

Mahmoud Taghizadeh <m_taghi@yahoo.com> writes:
> a dirty method to fix this bug is to replace following
> line 
> if (isdigit((unsigned char) *s) && dec < fpoint )
> with 
> if (isdigit((unsigned char) *s) && ((dec < fpoint) ||
> fpoint == 0))

This patch is wrong.  Something involving "!seen_dot || dec < fpoint"
would probably be better.  On the other hand, I can see half a dozen
other brokennesses in that routine on idly glancing over it :-(

Are you aware that the monetary type is deprecated and is going to be
dropped entirely pretty soon?  I would not recommend that you spend
any time on it, unless you want to commit to doing a wholesale rewrite.
Store your financial data in NUMERIC columns instead --- no overflow
worries, for one thing.

			regards, tom lane

Re: monetary bug

Mike Mascari <mascarm@mascari.com> — 2004-08-22T19:35:47Z

Tom Lane wrote:

> Mahmoud Taghizadeh <m_taghi@yahoo.com> writes:
> 
>>a dirty method to fix this bug is to replace following
> Are you aware that the monetary type is deprecated and is going to be
> dropped entirely pretty soon?

What's taking so long? ;-)

Mike Mascari

Re: monetary bug

Tom Lane <tgl@sss.pgh.pa.us> — 2004-08-22T19:40:10Z

Mike Mascari <mascarm@mascari.com> writes:
> Tom Lane wrote:
>> Are you aware that the monetary type is deprecated and is going to be
>> dropped entirely pretty soon?

> What's taking so long? ;-)

We keep hoping someone will step up to the plate and rewrite it, instead.
Per previous discussion, the type really ought to be a thin layer over
"numeric", with most likely no operations of its own except I/O conversion.

			regards, tom lane

Re: monetary bug

Peter Eisentraut <peter_e@gmx.net> — 2004-08-22T19:57:03Z

Tom Lane wrote:
> We keep hoping someone will step up to the plate and rewrite it,
> instead. Per previous discussion, the type really ought to be a thin
> layer over "numeric", with most likely no operations of its own
> except I/O conversion.

And what would it do with it?  Add a currency symbol?  Which one?  Which 
form?  Where?  Format the numbers some way?  Sounds like a big mess.  
Drop it and use to_char.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: monetary bug

Oliver Elphick <olly@lfix.co.uk> — 2004-08-22T19:57:43Z

On Sun, 2004-08-22 at 20:40, Tom Lane wrote:
> Mike Mascari <mascarm@mascari.com> writes:
> > Tom Lane wrote:
> >> Are you aware that the monetary type is deprecated and is going to be
> >> dropped entirely pretty soon?
> 
> > What's taking so long? ;-)
> 
> We keep hoping someone will step up to the plate and rewrite it, instead.
> Per previous discussion, the type really ought to be a thin layer over
> "numeric", with most likely no operations of its own except I/O conversion.

What are the parameters?  Is it an SQL type?

It seems to me a monetary type is a complex type consisting of currency
code and amount -- but you couldn't sum mixed currencies.  Or else it is
limited to the currency of the locale, which doesn't seem particularly
useful.

I think that it should be removed altogether.

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "For yourselves know perfectly that the day of the Lord
      so cometh as a thief in the night. For when they shall
      say, Peace and safety; then sudden destruction cometh 
      upon them, as travail upon a woman with child; and 
      they shall not escape."      I Thessalonians 5:2,3

Re: monetary bug

Tom Lane <tgl@sss.pgh.pa.us> — 2004-08-22T20:07:17Z

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> We keep hoping someone will step up to the plate and rewrite it,
>> instead. Per previous discussion, the type really ought to be a thin
>> layer over "numeric", with most likely no operations of its own
>> except I/O conversion.

> And what would it do with it?  Add a currency symbol?  Which one?  Which 
> form?  Where?  Format the numbers some way?

The idea behind the money type is to format per the lc_monetary locale
setting, which seems perfectly reasonable to me.  Further down the road
we might want per-column locale control, but when we haven't solved that
for text columns it's hardly fair to demand it of type money.

The big beef against the existing money type, IMHO, is the decision to
make the internal representation int32, which makes it hopelessly
overflow-prone.  Fix that and I'd stop telling people not to use it.

			regards, tom lane

Re: monetary bug

Tom Lane <tgl@sss.pgh.pa.us> — 2004-08-22T20:16:23Z

Oliver Elphick <olly@lfix.co.uk> writes:
> It seems to me a monetary type is a complex type consisting of currency
> code and amount -- but you couldn't sum mixed currencies.  Or else it is
> limited to the currency of the locale, which doesn't seem particularly
> useful.

In a former lifetime I worked with databases involving amounts of
different currencies, and I didn't find type money useful for that
either.  But I think that's a specialized requirement and we'd be
unlikely to consider putting a type that *is* useful for that into
the standard distribution.

I think the money type has very simple, limited goals: give me a numeric
column that has I/O format determined by the current LC_MONETARY setting.
Sure, that doesn't solve every money-related problem, but it would have
usefulness enough to justify the limited amount of implementation effort
involved.  The issues with the current implementation aren't really
related to that, they are related to a poor choice of underlying
representation.

> I think that it should be removed altogether.

If no one steps up and fixes it, eventually it will be.

			regards, tom lane

Re: monetary bug

Peter Eisentraut <peter_e@gmx.net> — 2004-08-22T20:34:07Z

Tom Lane wrote:
> The idea behind the money type is to format per the lc_monetary
> locale setting, which seems perfectly reasonable to me.

To me, this seems completely wrong-headed.  Data types should be defined 
by what operations you can do on them, not by what output format they 
have.  With that in mind, a money type that is separate from numeric 
types could be reasonable, because not all mathematical operations are 
reasonable on monetary amounts.  But most well-designed client 
interfaces nowadays reparse the text representations of data to present 
the datum in terms of the client's own data type system, so a money 
type with a varying and unpredictable output format cannot be 
reasonably supported and will only create headaches.  And even those 
client interfaces that don't fall into that category will have trouble, 
because for example you could have trouble sorting the values 
numerically.  So again, if you're looking for a certain display form, 
use the functions that were made for that purpose.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Re: monetary bug

D'Arcy Cain <darcy@druid.net> — 2004-08-22T21:15:11Z

On Sun, 22 Aug 2004 13:29:14 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Are you aware that the monetary type is deprecated and is going to be
> dropped entirely pretty soon?  I would not recommend that you spend
> any time on it, unless you want to commit to doing a wholesale
> rewrite. Store your financial data in NUMERIC columns instead --- no
> overflow worries, for one thing.

And if you have a table with 30,000,000+ records and need to sum a
subset of them 100 times per second expect some stress.

FWIW I have been working on a contrib module that stores the amount in a
64 bit integer.  Perhaps I should submit it as a patch to the existing
money type instead.  I have fixed up a few other issues while I was at
it.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: monetary bug

Hannu Krosing <hannu@tm.ee> — 2004-08-22T21:56:27Z

On P, 2004-08-22 at 23:07, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> We keep hoping someone will step up to the plate and rewrite it,
> >> instead. Per previous discussion, the type really ought to be a thin
> >> layer over "numeric", with most likely no operations of its own
> >> except I/O conversion.
> 
> > And what would it do with it?  Add a currency symbol?  Which one?  Which 
> > form?  Where?  Format the numbers some way?
> 
> The idea behind the money type is to format per the lc_monetary locale
> setting, which seems perfectly reasonable to me.

so if you put in $1.00 using en_US.UTF8 then another user using en_CA
would get 1.00CAD and I would get 1.00 EEK ?

It does make /some/ sense - I would be all for that if this is the sum I
mus pay, but object strongly if the sum must be paid *to* me ;)

--------------
Hannu

Re: monetary bug

Greg Stark <gsstark@mit.edu> — 2004-08-22T22:36:14Z

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Oliver Elphick <olly@lfix.co.uk> writes:
> > It seems to me a monetary type is a complex type consisting of currency
> > code and amount -- but you couldn't sum mixed currencies.  Or else it is
> > limited to the currency of the locale, which doesn't seem particularly
> > useful.
> 
> In a former lifetime I worked with databases involving amounts of
> different currencies, and I didn't find type money useful for that
> either.  But I think that's a specialized requirement and we'd be
> unlikely to consider putting a type that *is* useful for that into
> the standard distribution.

Actually I think dimensioned values, or quantities with units attached, would
be a very useful datatype for lots of purposes. Both accounting and scientific
purposes often need to store things in heterogenous units but then be sure not
to perform any inappropriate operations on them. Even if it just asserted that
the units matched and permitted the operation it would be useful, without
trying to do any fancy dimensional calculus to come up with things like m^2 or
m/s etc.

fwiw, I agree with the other poster that data types ought to be defined by the
operations performed on them, not the display format. In particular I would
expect the application to be able to multiply or add to a value pulled from a
database even if it's a monetary value, and that wouldn't work if the database
insisted on attaching units. It should be the job of strfmon or equivalent to
format the value for display.

Perhaps what people are really looking for is some kind of column attribute to
define the "default" display format to be used. So that applications don't
have to hard code parameters to to_char(). There are solutions at the
application layer for that, but I could see it being useful to be able to call
to_char(column) and have the column know which parameters by default whether
it's a date column, numeric column, or cidr datatype.

-- 
greg

Re: NLS support for postgreSQL

Shachar Shemesh <psql@shemesh.biz> — 2004-08-22T23:49:04Z

Mahmoud Taghizadeh wrote:

>3. we are planning to add locale per column for
>postgreSQL, but I found that you had said its
>impossible.  am I right? do you have any paper about
>it?
>  
>
One of the ways to solve this is to have a special data type for this 
purpose. Check out the mssqlext project on pgfoundry 
(http://pgfoundry.org/projects/sql2pg/). In particular, check out the 
"varcharci" type, that has case preserving varchars. This may provide 
you with a starting point for what you are trying to do.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/

Re: NLS support for postgreSQL

Robert Treat <xzilla@users.sourceforge.net> — 2004-08-23T02:45:13Z

On Sunday 22 August 2004 07:53, Mahmoud Taghizadeh wrote:
> 1. we want to translate some postgreSql documents
> (FAQ, tutorial for start). I want to know who is
> responsible for this part in postgreSQL (we are from
> IRAN)
>

If you translate the FAQ, make sure it is the html version 
(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/doc/src/FAQ/FAQ.html). 
Once you are done you can submit it to pgsql-patches for commital, at which 
point it should get picked up into the web site. 

As for the tutorial, you are free to translate that and host it locally, or we 
could probably make some room up on techdocs if you want. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: monetary bug

Dennis Björklund <db@zigo.dhs.org> — 2004-08-23T04:49:33Z

On Sun, 22 Aug 2004, Peter Eisentraut wrote:

> To me, this seems completely wrong-headed.  Data types should be defined 
> by what operations you can do on them, not by what output format they 
> have.

I totally agree, lets get rid of money all together.

If not, what makes money so special? Do we want other numeric types like 
hexnumber, octalnamber, weight, length, ... All of these are different 
ways to format a number in a user interface.

Of course one could imaging a system with units, so that if you multiplty
two lengths (meter) you get an area (meter^2) and so on.. But it's just
going to be complicated and no other programming language I know of have
gone that way.

-- 
/Dennis Björklund

Re: monetary bug

Karel Zak <zakkr@zf.jcu.cz> — 2004-08-23T10:45:36Z

On Sun, Aug 22, 2004 at 04:07:17PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> We keep hoping someone will step up to the plate and rewrite it,
> >> instead. Per previous discussion, the type really ought to be a thin
> >> layer over "numeric", with most likely no operations of its own
> >> except I/O conversion.
> 
> > And what would it do with it?  Add a currency symbol?  Which one?  Which 
> > form?  Where?  Format the numbers some way?

 I'm sure  you found  answers in "struct  lconv" (locale.h),  but you're
 right (IMHO) better is if datetypes are independent on format.

 What support  some argument definition in  column definition, something
 like:

     CREATE TABLE tab (
          -- curret built-in datetype in/out format
          num            numeric,
          
          -- default user defined format  
          num2           numeric WITH FORMAT,

          -- column specific format
          payme          numeric WITH FORMAT='L 999D99',
          
          temperature    numeric WITH FORMAT='999D999 C',
     );

 where format producer for datetype is possible (re)define by:
 
     CREATE FORMATTER FOR numeric 
        DEFAULT format INPUT funcname OUTPUT funcname;

 The columns without "FORMAT" options will use standard (current) in/out
 methods. Outputs  without  connection  to  some  table  column  can  be
 formated by:

    -- curret built-in datetype in/out format
    SELECT expr;

    -- default defined format
    SELECT FORMAT( expr );
 
    -- specific format
    SELECT FORMAT( expr AS 'DD/MM/YYYY' );

 I  think it's  pretty extendable  solution in  contrast to  the current
 hardcoded  in/out  datetypes  functions.

 Comments?

 Is there any plan for locale-per-column setting syntax?

> The idea behind the money type is to format per the lc_monetary locale
> setting, which seems perfectly reasonable to me.  Further down the road

 Why "money" and why not  others things like temperature, speed, weight,
 ...?

    Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

Re: monetary bug

Dennis Björklund <db@zigo.dhs.org> — 2004-08-23T12:52:44Z

On Mon, 23 Aug 2004, Karel Zak wrote:

>  I  think it's  pretty extendable  solution in  contrast to  the current
>  hardcoded  in/out  datetypes  functions.

Who are we formatting for? If the client wants the data in a specific
format then they can do SELECT to_char(...), or do the formatting in the
client all together.

If some client wants to render the column value as a bitmap image, let
them.  We don't need to build in everything a client wants to do in the
server.

The database should manage data, presenting it to the user in different 
ways are the job of a client.

-- 
/Dennis Björklund

Re: monetary bug

Mike Mascari <mascarm@mascari.com> — 2004-08-23T13:11:18Z

Dennis Bjorklund wrote:
> On Sun, 22 Aug 2004, Peter Eisentraut wrote:
> 
>>To me, this seems completely wrong-headed.  Data types should be defined 
>>by what operations you can do on them, not by what output format they 
>>have.
> 
> I totally agree, lets get rid of money all together.
> 
> If not, what makes money so special? Do we want other numeric types like 
> hexnumber, octalnamber, weight, length, ... All of these are different 
> ways to format a number in a user interface.

MONEY seems "odd" because it is interpreting its internal 
representation based upon locale and the locale is also determining 
its possible representation, so one database's MONEY isn't really 
the same type as another database's MONEY.

However, Date & Darwen's type model suggests that a database should 
have support for types like WEIGHT, LENGTH, and TEMPERATURE, 
although they could certainly be left for the user to define. They 
define possible representations and THE_ functions as the means to 
support multiple units (among other purposes.) For example, a LENGTH 
type would have the following selector functions:

LENGTH LENGTH_IN_INCHES(NO_OF_INCHES RATIONAL);
LENGTH LENGTH_IN_FEET(NO_OF_FEET RATIONAL);
LENGTH LENGTH_IN_CM(NO_OF_CM RATIONAL);

Its internal representation would be irrelevant to the user, 
although the way PostgreSQL's type extensibility system works, it 
would need to have a default unit. It would also have THE_ functions 
like:

RATIONAL THE_NO_OF_INCHES(LENGTH);
RATIONAL THE_NO_OF_FEET(LENGTH);
RATIONAL THE_NO_OF_CM(LENGTH);

A DISPLAY() function is invoked to display the type in its default 
representation and if one is not defined, an error occurs in D & D's 
model. If there must be one, then it would generate unambiguous 
output like:

'8.13 inches'

And of course, the various types would be constrained appropriately. 
One couldn't have a negative LENGTH or a TEMPERATURE under absolute 
zero, as examples. I think it would be neat to have an external 
library supporting a large set of types like these.

Mike Mascari

Re: monetary bug

Karel Zak <zakkr@zf.jcu.cz> — 2004-08-23T14:07:29Z

On Mon, Aug 23, 2004 at 02:52:44PM +0200, Dennis Bjorklund wrote:
> On Mon, 23 Aug 2004, Karel Zak wrote:
> 
> >  I  think it's  pretty extendable  solution in  contrast to  the current
> >  hardcoded  in/out  datetypes  functions.
> 
> Who are we formatting for? If the client wants the data in a specific
> format then they can do SELECT to_char(...), or do the formatting in the
> client all together.

 Yes. But some people call for datetypes with integrated formatting (for
 example  "money"). I  think  we  should support  _common_  way  how  do
 formatting  (not only  for "money")  _OR_ we  should reject  types like
 "money" and do formatting only by extra functions like to_char().

> The database should manage data, presenting it to the user in different 
> ways are the job of a client.

 Sure, do you want to read data in binary format that PostgreSQL uses in
 db files  or do you expect  it in some nice  string? PostgreSQL already
 does  data  formating almost  for  all  datetypes  -- see  sources  and
 datetypes in/out functions.

    Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

Re: monetary bug

Oliver Elphick <olly@lfix.co.uk> — 2004-08-23T14:19:26Z

On Mon, 2004-08-23 at 14:11, Mike Mascari wrote:
...
> MONEY seems "odd" because it is interpreting its internal 
> representation based upon locale and the locale is also determining 
> its possible representation, so one database's MONEY isn't really 
> the same type as another database's MONEY.
> 
> However, Date & Darwen's type model suggests that a database should 
> have support for types like WEIGHT, LENGTH, and TEMPERATURE, 
> although they could certainly be left for the user to define. They 
> define possible representations and THE_ functions as the means to 
> support multiple units (among other purposes.) For example, a LENGTH 
> type would have the following selector functions:
> 
> LENGTH LENGTH_IN_INCHES(NO_OF_INCHES RATIONAL);
> LENGTH LENGTH_IN_FEET(NO_OF_FEET RATIONAL);
> LENGTH LENGTH_IN_CM(NO_OF_CM RATIONAL);

The difference between these and money is that there is a constant
relationship between units; you may measure a distance in inches or
centimetres, but it is always the same distance.  The conversions
between different units of money vary minute by minute.  Furthermore the
unit of money is very important, whereas the unit of length is not.  You
cannot meaningfully add amounts of money in different currencies, even
if you convert to some base currency first.  

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "For God hath not appointed us to wrath, but to obtain 
      salvation by our Lord Jesus Christ, Who died for us, 
      that, whether we wake or sleep, we should live  
      together with him."     
                         I Thessalonians 5:9,10