Re: More new SQL/JSON item methods

Поиск
Список
Период
Сортировка
От Jeevan Chalke
Тема Re: More new SQL/JSON item methods
Дата
Msg-id CAM2+6=XKs_pAw9in6=h-RUy9i58km0vAwmoGRcWe4QrF5ZVM0A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: More new SQL/JSON item methods  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: More new SQL/JSON item methods  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers


On Mon, Jan 29, 2024 at 11:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kyotaro Horiguchi <horikyota.ntt@gmail.com> 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, Manager
Product Development




edbpostgres.com
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sutou Kouhei
Дата:
Сообщение: Re: Make COPY format extendable: Extract COPY TO format implementations
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: meson + libpq_pipeline