|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>|
|Cc:||PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Infinities in type numeric|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> I had a look at this, and I think it's mostly in good shape. It looks
> like everything from the first message in this thread has been
> resolved, except I don't know about the jsonpath stuff, because I
> haven't been following that.
Thanks for the careful review! Yeah, Alexander fixed the jsonpath
stuff at df646509f, so I think all my original concerns are cleared,
other than the question of whether to invent isfinite() and isnan()
SQL functions. That seems like follow-on work in any case.
> 1). I don't think that the way in_range() handles infinities is quite
> right. For example:
> SELECT in_range('inf'::numeric, 10::numeric, 'inf'::numeric, false, false);
> (1 row)
> But I think that should return "val >= base + offset", which is "Inf
> >= Inf", which should be true.
Hmm. I modeled the logic on the float8 in_range code, which does the
# SELECT in_range('inf'::float8, 10::float8, 'inf'::float8, false, false);
It does seem like this is wrong per the specification of in_range, though,
so do we have a bug to fix in the float in_range support? If so I'd
be inclined to go correct that first and then adapt the numeric patch
> Similarly, I think this should return true:
> SELECT in_range('-inf'::numeric, 10::numeric, 'inf'::numeric, true, true);
> I think this could use some test coverage.
> 2). I think numeric_pg_lsn() needs updating -- this should probably be an error:
Oh, that was not there when I produced my patch. Will cover it in the
I agree with your other comments and will update the patch.
> Finally, not really in the scope of this patch, but something I
> noticed anyway while looking at edge cases -- float and numeric handle
> NaN/0 differently:
> SELECT 'nan'::float8 / 0::float8;
> ERROR: division by zero
> SELECT 'nan'::numeric / 0::numeric;
Hmm. It seems like we generally ought to try to follow IEEE 754
for the semantics of operations on NaN, but I don't have a copy of
that spec so I'm not sure which result it specifies for this.
I agree that being inconsistent between the two types is not what
regards, tom lane
|Next Message||Andy Fan||2020-07-16 16:52:00||Difference for Binary format vs Text format for client-server communication|
|Previous Message||Alexey Kondratov||2020-07-16 16:40:05||Re: Partitioning and postgres_fdw optimisations for multi-tenancy|