Re: Wish List: Client access to NUMERIC/DECIMAL type functions - Mailing list pgsql-interfaces

From Warren W. Gay VE3WWG
Subject Re: Wish List: Client access to NUMERIC/DECIMAL type functions
Date
Msg-id 3D2EDFBA.1010704@cogeco.ca
Whole thread Raw
In response to Wish List: Client access to NUMERIC/DECIMAL type functions  ("Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>)
Responses Re: Wish List: Client access to NUMERIC/DECIMAL type functions
List pgsql-interfaces
Jan Wieck wrote:

>"Warren W. Gay VE3WWG" wrote:
>
>>It would be nice to see client side access to the decimal
>>routines used by PostgreSQL to support the decimal/numeric
>>data types. Are there any plans for that to happen?
>>
>
>If you mean to make the arbitrary precision arithmetic available inside
>of the libpq, no there are no such plans.
>
Yes.

>The functions, which you can find in src/backend/utils/adt/numeric.c,
>are designed and optimized to live inside of the PostgreSQL database
>backend. There are several other arbitrary precision packages out in the
>world, that fit alot better into client applications. 
>
I understand the "optimized" position.  But the rest does not make sense 
to me.

If I use the binary interface, I now have to convert your "decimal" number
to someone else's format, so I can do something with it.  

Oracle or INFORMIX OTOH, provide the user access to
routines to manipulate their builtin data types.  This is what
I would hope that PostgreSQL's client interface would work
towards.  It would certainly make it a lot more "client friendly".

As far as other "decimal" packages in the Open Source wild, I don't know 
of any,
but I'll admit that I've not looked too hard yet.
The GNU GMP is a multi-precision INTEGER or fraction library, but doesn't
support what is needed.  If you know differently, I welcome links. But I 
still
maintain that it makes the most sense, to have PostgreSQL native support
for their special builtin types.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg




pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: arrays as input parameter for c functions
Next
From: Michael Meskes
Date:
Subject: Re: ECPG Questions