From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Bowen Shi <zxwsbg12138(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Comparing two double values method |
Date: | 2023-10-10 14:13:36 |
Message-ID: | 321699.1696947216@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 10/10/2023 13:31, Bowen Shi wrote:
>> I noticed that in the `check_GUC_init` function, there is a direct
>> comparison using the != operator for two double values, which seems
>> problematic.
> No, the compile-time initial values should match exactly.
Right. The point of this test is to catch cases where you wrote,
say,
double my_guc = 1.1;
but the boot_val for it in guc_tables.c is 1.2. There is no
reason to allow any divergence in the spellings of the two C
literals, so as long as they're compiled by the same compiler
there's no reason to expect that the compiled values wouldn't
be bit-equal.
The point of the exclusions for zero is to allow you to just
write
double my_guc;
without expressing an opinion about the initial value.
(Yes, this does mean that "double my_guc = 0.0;" could
be misleading. It's just a heuristic though.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-10-10 14:25:04 | Re: Request for comment on setting binary format output per session |
Previous Message | Robert Haas | 2023-10-10 14:12:36 | Re: CHECK Constraint Deferrable |