Alexander Korotkov writes:
> On Thu, Jul 9, 2020 at 4:04 AM Alexander Korotkov
> wrote:
>> I understand both patches as fixes and propose to backpatch them to 12
>> if no objections.
> Both patches are pushed.
Thanks for taking care of that!
regards, tom lane
On Thu, Jul 9, 2020 at 4:04 AM Alexander Korotkov wrote:
> I understand both patches as fixes and propose to backpatch them to 12
> if no objections.
Both patches are pushed.
--
Regards,
Alexander Korotkov
On Thu, Jul 9, 2020 at 1:20 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > The patchset is attached, sorry for the delay.
>
> > The first patch improves error messages, which appears to be unclear
> > for me. If one applies .double() method to a numeric value, we
> > restrict that this
Alexander Korotkov writes:
> The patchset is attached, sorry for the delay.
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric value should fit to double precision type.
> If it
On Wed, Jul 8, 2020 at 1:16 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push 0002 if there is no objection.
> > Regarding 0001, I think my new error messages need review.
>
> I do intend to review these, just didn't get to it yet.
OK, that you for noticing. I wouldn't push
Alexander Korotkov writes:
> I'm going to push 0002 if there is no objection.
> Regarding 0001, I think my new error messages need review.
I do intend to review these, just didn't get to it yet.
regards, tom lane
On Mon, Jul 6, 2020 at 3:19 PM Alexander Korotkov wrote:
> The patchset is attached, sorry for the delay.
>
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric value should fit to
On Thu, Jun 18, 2020 at 8:04 PM Alexander Korotkov
wrote:
> On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > Thank you for your answer. I'm trying to understand your point.
> > > Standard claims that .double() method should behave the same way as
> > > CAST
On 6/18/20 12:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov
>> wrote:
>>> The problem is that we tried to find a trade-off between standard and
>>> postgres
>>> implementation, for example, in postgres CAST allows NaN and Inf, and SQL
>>>
On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Thank you for your answer. I'm trying to understand your point.
> > Standard claims that .double() method should behave the same way as
> > CAST to double. However, standard references the standard behavior of
> >
Alexander Korotkov writes:
> Thank you for your answer. I'm trying to understand your point.
> Standard claims that .double() method should behave the same way as
> CAST to double. However, standard references the standard behavior of
> CAST here, not behavior of your implementation of CAST.
On Thu, Jun 18, 2020 at 7:34 PM Alexander Korotkov
wrote:
> Thank you for your answer. I'm trying to understand your point.
> Standard claims that .double() method should behave the same way as
> CAST to double. However, standard references the standard behavior of
> CAST here, not behavior of
Robert Haas writes:
> On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov
> wrote:
>> The problem is that we tried to find a trade-off between standard and
>> postgres
>> implementation, for example, in postgres CAST allows NaN and Inf, and SQL
>> Standard
>> requires .double should works as
Tom,
On Thu, Jun 18, 2020 at 7:07 PM Tom Lane wrote:
> Oleg Bartunov writes:
> > The problem is that we tried to find a trade-off between standard and
> > postgres implementation, for example, in postgres CAST allows NaN and
> > Inf, and SQL Standard requires .double should works as CAST.
>
>
On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov wrote:
> The problem is that we tried to find a trade-off between standard and
> postgres
> implementation, for example, in postgres CAST allows NaN and Inf, and SQL
> Standard
> requires .double should works as CAST.
It seems like the right
Oleg Bartunov writes:
> The problem is that we tried to find a trade-off between standard and
> postgres implementation, for example, in postgres CAST allows NaN and
> Inf, and SQL Standard requires .double should works as CAST.
As I said, I think this is a fundamental misreading of the
On Wed, Jun 17, 2020 at 6:33 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
> >> I don't think this is very relevant. The SQL standard has not got the
> >> concepts of Inf or NaN either (see 4.4.2 Characteristics of numbers),
> >>
Alexander Korotkov writes:
> On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
>> I don't think this is very relevant. The SQL standard has not got the
>> concepts of Inf or NaN either (see 4.4.2 Characteristics of numbers),
>> therefore their definition is only envisioning that a string
On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
> >> It is entirely clear from the code, the documentation,
> >> and the relevant RFCs that JSONB does not allow NaNs as numeric
> >> values.
>
> > The JSONB
Alexander Korotkov writes:
> On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
>> It is entirely clear from the code, the documentation,
>> and the relevant RFCs that JSONB does not allow NaNs as numeric
>> values.
> The JSONB itself doesn't store number NaNs. It stores the string "NaN".
Yeah,
Hi Tom,
Thank you for raising this issue.
On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
> Commit 72b646033 inserted this into convertJsonbScalar:
>
> break;
>
> case jbvNumeric:
> + /* replace numeric NaN with string "NaN" */
> +
Commit 72b646033 inserted this into convertJsonbScalar:
break;
case jbvNumeric:
+ /* replace numeric NaN with string "NaN" */
+ if (numeric_is_nan(scalarVal->val.numeric))
+ {
+
22 matches
Mail list logo
