public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jeevan Chalke <[email protected]>
To: Tom Lane <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: More new SQL/JSON item methods
Date: Tue, 30 Jan 2024 13:46:17 +0530
Message-ID: <CAM2+6=XKs_pAw9in6=h-RUy9i58km0vAwmoGRcWe4QrF5ZVM0A@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAM2+6=V1euSMRnYPv7s7JCndFk_3rfmaSny6So2+VJs2Xxd6Hw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Mon, Jan 29, 2024 at 11:03 AM Tom Lane <[email protected]> wrote:
> Kyotaro Horiguchi <[email protected]> writes:
> > Having said that, I'm a bit concerned about the case where an overly
> > long string is given there. However, considering that we already have
> > "invalid input syntax for type xxx: %x" messages (including for the
> > numeric), this concern might be unnecessary.
>
> Yeah, we have not worried about that in the past.
>
> > Another concern is that the input value is already a numeric, not a
> > string. This situation occurs when the input is NaN of +-Inf. Although
> > numeric_out could be used, it might cause another error. Therefore,
> > simply writing out as "argument NaN and Infinity.." would be better.
>
> Oh! I'd assumed that we were discussing a string that we'd failed to
> convert to numeric. If the input is already numeric, then either
> the error is unreachable or what we're really doing is rejecting
> special values such as NaN on policy grounds. I would ask first
> if that policy is sane at all. (I'd lean to "not" --- if we allow
> it in the input JSON, why not in the output?) If it is sane, the
> error message needs to be far more specific.
>
> regards, tom lane
>
*Consistent error message related to type:*
Agree that the number is not a PostgreSQL type and needs a change. As Tom
suggested, we can say "type numeric" here. However, I have seen two
variants of error messages here: (1) When the input is numeric and (2) when
the input is string. For first, we have error messages like:
numeric argument of jsonpath item method .%s() is out of range for type
double precision
and for the second, it is like:
string argument of jsonpath item method .%s() is not a valid representation
of a double precision number
The second form says "double precision number". So, in the decimal/number
case, should we use "numeric number" and then similarly "big integer
number"?
What if we use phrases like "for type double precision" at both places,
like:
numeric argument of jsonpath item method .%s() is out of range for type
double precision
string argument of jsonpath item method .%s() is not a valid representation
for type double precision
With this, the rest will be like:
for type numeric
for type bigint
for type integer
Suggestions?
---
*Showing input string in the error message:*
argument "...input string here..." of jsonpath item method .%s() is out of
range for type numeric
If we add the input string in the error, then for some errors, it will be
too big, for example:
-ERROR: numeric argument of jsonpath item method .double() is out of range
for type double precision
+ERROR: argument
"10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
of jsonpath item method .double() is out of range for type double precision
Also, for non-string input, we need to convert numeric to string just for
the error message, which seems overkill.
On another note, irrespective of these changes, is it good to show the
given input in the error messages? Error messages are logged and may leak
some details.
I think the existing way seems ok.
---
*NaN and Infinity restrictions:*
I am not sure why NaN and Infinity are not allowed in conversion to double
precision (.double() method). I have used the same restriction for
.decimal() and .number(). However, as you said, we should have error
messages more specific. I tried that in the attached patch; please have
your views. I have the following wordings for that error message:
"NaN or Infinity is not allowed for jsonpath item method .%s()"
Suggestions...
Thanks
--
Jeevan Chalke
*Principal, ManagerProduct Development*
edbpostgres.com
Attachments:
[application/octet-stream] improve_error_for_Nan_Infinity.patch.no (6.9K, ../CAM2+6=XKs_pAw9in6=h-RUy9i58km0vAwmoGRcWe4QrF5ZVM0A@mail.gmail.com/3-improve_error_for_Nan_Infinity.patch.no)
download
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: More new SQL/JSON item methods
In-Reply-To: <CAM2+6=XKs_pAw9in6=h-RUy9i58km0vAwmoGRcWe4QrF5ZVM0A@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox