Re: New version of money type

Theo Schlossnagle <jesus@omniti.com> writes:

> Would that pose indexing issues?  It would also mean that when joining two
> tables you'd have to handle some interesting type  conversion issues (at
> times).  We had someone accidentally create a  largish table with userid as
> "numeric" and other tables are "bigint",  it was disastrous for performance
> (joining).  I'd imagine that if the  above wasn't done cleverly, that
> performance problem would be repeated.

That used to be a problem but Tom solved it a little while back. Not a perfect
solution in that it requires lots of cross-data-type operators as the number
of data types grows but it works.

In any case I think Jim was suggesting this be handled internally to the
numeric data type which wouldn't cause this problem. However I'm not sure
anything has to be done. A numeric is an array of 16 bit integers, so anything
under 64k *is* stored just as an integer. 

Well, just an integer plus a useless exponent. I think it would be a neat
trick to normalize the exponent to the end of the last element of the mantissa
rather than the first digit so that integers don't need an exponent.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com