Re: T_Float morph to T_Integer after nodeRead

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: T_Float morph to T_Integer after nodeRead
Date: 2017-01-06 02:08:56
Message-ID: 9A28C8860F777E439AA12E8AEA7694F801281DC7@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> > Simplified description of what I did is:
> > fval = makeFloat(psprintf("%.0f", plan_nrows));
> > custom_scan->custom_private = list_make1(fval);
>
> So don't do that. The lexer would never produce T_Float for an
> integer-looking string, so I think it's out of scope for nodeRead() to be
> able to reconstitute such a thing. You could use %.1f, perhaps.
> But actually, if you're worried about reconstituting exactly what you had,
> aren't you risking precision loss anyway? Maybe something like
> psprintf("%.*e", DBL_DIG+3, plan_nrows) would be safer.
>
Ah, indeed, it is a good idea to avoid the problem.

Thanks,
----
PG-Strom Project / NEC OSS Promotion Center
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vitaly Burovoy 2017-01-06 02:39:09 Re: Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints
Previous Message Bruce Momjian 2017-01-06 02:03:35 Re: Indirect indexes