pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedgcc _Decimal types & ecpg
3+ messages / 2 participants
[nested] [flat]
* gcc _Decimal types & ecpg
@ 2008-12-12 05:22 Bosco Rama <postgres@boscorama.com>
0 siblings, 1 reply; 3+ messages in thread
From: Bosco Rama @ 2008-12-12 05:22 UTC (permalink / raw)
To: pgsql-interfaces
Hi folks,
I was wondering if ecpg from Postgresql 8.3.5 is able to handle the gcc4 _Decimal32,
_Decimal64 & _Decimal128 intrinsic data types as transparently as the other types?
Or do they just end up getting treated as simple C float/double?
TIA.
Bosco.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: gcc _Decimal types & ecpg
@ 2008-12-14 12:26 Michael Meskes <meskes@postgresql.org>
parent: Bosco Rama <postgres@boscorama.com>
0 siblings, 1 reply; 3+ messages in thread
From: Michael Meskes @ 2008-12-14 12:26 UTC (permalink / raw)
To: Bosco Rama <postgres@boscorama.com>; +Cc: pgsql-interfaces
On Thu, Dec 11, 2008 at 09:22:03PM -0800, Bosco Rama wrote:
> I was wondering if ecpg from Postgresql 8.3.5 is able to handle the gcc4 _Decimal32,
> _Decimal64 & _Decimal128 intrinsic data types as transparently as the other types?
> Or do they just end up getting treated as simple C float/double?
To be honest I haven't heard/thought about these datatypes before. Could you
give me a pointer where to find more information? Are these types similar to
our decimal/numeric types?
The parser does not recognize these type keywords. So yes, atm they have to be treated
as float/double.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: gcc _Decimal types & ecpg
@ 2008-12-14 17:30 Bosco Rama <postgres@boscorama.com>
parent: Michael Meskes <meskes@postgresql.org>
0 siblings, 0 replies; 3+ messages in thread
From: Bosco Rama @ 2008-12-14 17:30 UTC (permalink / raw)
To: Bosco Rama <postgres@boscorama.com>; pgsql-interfaces
Hi Michael,
Michael Meskes wrote:
> On Thu, Dec 11, 2008 at 09:22:03PM -0800, Bosco Rama wrote:
>> I was wondering if ecpg from Postgresql 8.3.5 is able to handle the gcc4 _Decimal32,
>> _Decimal64 & _Decimal128 intrinsic data types as transparently as the other types?
>> Or do they just end up getting treated as simple C float/double?
>
> To be honest I haven't heard/thought about these datatypes before. Could you
> give me a pointer where to find more information? Are these types similar to
> our decimal/numeric types?
These are the Decimal Floating Point types with storage bit-widths of 32, 64, 128.
They are part of the IEEE-754 2008 spec and have been added to the C99 spec as an
extension and have been in gcc since early in the 4 series. The GCC docs don't
have much on this:
<http://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html;
But these guys do: <http://speleotrove.com/decimal;
I don't know how closely it would match your decimal/numeric types internally but
I believe you could specify matching NUMERIC(x,y) declarations for them.
> The parser does not recognize these type keywords. So yes, atm they have to be treated
> as float/double.
I wonder if there will be conversion/cast issues with that? I'll have to look
closer to find out. We may just end us storing them as text/varchar.
Thanks.
Bosco.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2008-12-14 17:30 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-12-12 05:22 gcc _Decimal types & ecpg Bosco Rama <postgres@boscorama.com>
2008-12-14 12:26 ` Michael Meskes <meskes@postgresql.org>
2008-12-14 17:30 ` Bosco Rama <postgres@boscorama.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox