Re: floating point representation

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: floating point representation
Date: 2001-02-20 01:41:52
Message-ID: 3A91CB60.307F8744@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-02-20 02:02:17 Re: floating point representationu
Previous Message Hiroshi Inoue 2001-02-20 00:51:12 Re: Performance-improvement idea: shortcircuit unique-indexchecks