Re: More new SQL/JSON item methods

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: jeevan(dot)chalke(at)enterprisedb(dot)com, andrew(at)dunslane(dot)net, peter(at)eisentraut(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: More new SQL/JSON item methods
Date: 2024-01-29 05:12:40
Message-ID: 20240129.141240.1988354480093375317.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Sun, 28 Jan 2024 22:47:02 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote in
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> > They seem to be suggesting that PostgreSQL has the types
> "decimal" and
> > "number". I know of the former, but I don't think PostgreSQL has
> the
> > latter type. Perhaps the "number" was intended to refer to
> "numeric"?
>
> Probably. But I would write just "type numeric". We do not
> generally
> acknowledge "decimal" as a separate type, because for us it's only
> an
> alias for numeric (there is not a pg_type entry for it).
>
> Also, that leads to the thought that "numeric argument ... is out of
> range for type numeric" seems either redundant or contradictory
> depending on how you look at it. So I suggest wording like
>
> argument "...input string here..." of jsonpath item method .%s() is
> out of range for type numeric
>
> > (And I think it is largely helpful if the given string were shown
> in
> > the error message, but it would be another issue.)
>
> Agreed, so I suggest the above.

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.

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.

Once we resolve these issues, another question arises regarding on of
the messages. In the case of NaN of Infinity, the message will be as
the follows:

"argument NaN or Infinity of jsonpath item method .%s() is out of
range for type numeric"

This message appears quite strange and puzzling. I suspect that the
intended message was somewhat different.

> > The same commit has introduced the following set of messages:
>
> >> %s format is not recognized: "%s"
> >> date format is not recognized: "%s"
> >> time format is not recognized: "%s"
> >> time_tz format is not recognized: "%s"
> >> timestamp format is not recognized: "%s"
> >> timestamp_tz format is not recognized: "%s"
>
> > I believe that the first line was intended to cover all the
> others:p
>
> +1

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-01-29 05:25:57 Re: Update the doc that refers to the removed column of pg_replication_slots.
Previous Message Zhijie Hou (Fujitsu) 2024-01-29 05:08:15 Update the doc that refers to the removed column of pg_replication_slots.