From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql 10.19 : "ERROR: cannot convert infinity to numeric" except there is no infinity |
Date: | 2022-07-19 17:32:32 |
Message-ID: | 0d1a9696-db2d-ace7-5879-16fed625386a@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/19/22 10:26 AM, Achilleas Mantzios wrote:
> Thank you Adrian!
Actually thank:
>
> Στις 19/7/22 18:36, ο/η Adrian Klaver έγραψε:
>> On 7/19/22 03:38, Achilleas Mantzios wrote:
>>
>> I reformatted queries to see thing better.
>>
>>>
>> AND numrange(ceptl.min_alarm::numeric, ceptl.max_alarm::numeric, '()')
>> @> cept.value::numeric
>> ORDER BY
>> 1;
>>
>> So the above fails. In your title when you say there is no infinity
>> that means the cept.value, ceptl.min_alarm or ceptl.max_alarm fields
>> do not have any '-infinity' or 'infinity' values, correct?
> There is infinity in cept.value , just not in this result set.
> I got confused and wrongly assumed that since the result set (without
> the filter in the WHERE clause including cept.value::numeric) did not
> contain any infinity it should also work with the filter in the WHERE
> clause. Apparently a subplan executes this conversion in the WHERE
> before the other filters. I did not do any analyze to prove this.
>>
Have you tried:
NULLIF(cept.value, 'inf')::numeric
>>> --
>>> Achilleas Mantzios
>>> DBA, Analyst, IT Lead
>>> IT DEPT
>>> Dynacom Tankers Mgmt
>>>
>>
>>
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2022-07-19 17:42:19 | Re: pgsql 10.19 : "ERROR: cannot convert infinity to numeric" except there is no infinity |
Previous Message | David G. Johnston | 2022-07-19 17:31:08 | Re: pgsql 10.19 : "ERROR: cannot convert infinity to numeric" except there is no infinity |