Re: floating point representation - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: floating point representation
Date
Msg-id 3A91CB60.307F8744@tpf.co.jp
Whole thread Raw
In response to Re: floating point representation  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: floating point representationu  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Actually, you're going to have to recode the float*in() functions, using
> > scanf, and scanf's formats are not always equivalent to printf's.
> 
> Further thought: one answer to this is to institute four SET variables,
> two for output and two for input; perhaps FLOAT8_FORMAT, FLOAT8_IN_FORMAT,
> and similarly for FLOAT4.  The input formats would normally just be
> "%lg" and "%g" but could be changed for special cases (like reading
> table dumps prepared with %a output format).
> 

From the first I don't want to change the current default
output format"%." #FLT_DIG "g" (REAL)"%." #DBL_DIG "g" (DOUBLE PRECISION)
for 7.1 because their changes would cause a regress
test failure.

> However, it's becoming quite clear to me that this feature needs more
> thought than first appeared.  Accordingly, I now vote that we not try
> to fit it into 7.1, but do it in a more considered fashion for 7.2.
> 

The simplest way to fix it quickly would be to not provide
XXXX_IN_FORMAT and restrict XXXX_FORMAT to "%.*g" at present.

Regards,
Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Performance-improvement idea: shortcircuit unique-indexchecks
Next
From: Bruce Momjian
Date:
Subject: Re: floating point representationu