Re: More new SQL/JSON item methods

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>

To: Jeevan Chalke <jeevan.chalke@enterprisedb.com>, Peter Eisentraut <peter@eisentraut.org>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2024-01-25T15:40:26Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Rationalize and improve error messages for some jsonpath items
- 92d2ab7554f9 17.0 landed
Clean up a bug in sql/json items commit 66ea94e8e6
- 06a66d87dbc7 17.0 landed
Implement various jsonpath methods
- 66ea94e8e606 17.0 cited
Reorganise jsonpath operators and methods
- 283a95da9236 17.0 landed
Add numeric_int8_opt_error() to optionally suppress errors
- c1b9e1e56d8c 17.0 landed

On 2024-01-18 Th 09:25, Jeevan Chalke wrote:
>
>
> On Thu, Jan 18, 2024 at 1:03 AM Peter Eisentraut 
> <peter@eisentraut.org> wrote:
>
>     On 17.01.24 10:03, Jeevan Chalke wrote:
>     > I added unary '+' and '-' support as well and thus thought of
>     having
>     > separate rules altogether rather than folding those in.
>     >
>     >     Per SQL standard, the precision and scale arguments are unsigned
>     >     integers, so unary plus and minus signs are not supported. 
>     So my patch
>     >     removes that support, but I didn't adjust the regression
>     tests for that.
>     >
>     >
>     > However, PostgreSQL numeric casting does support a negative
>     scale. Here
>     > is an example:
>     >
>     > # select '12345'::numeric(4,-2);
>     >   numeric
>     > ---------
>     >     12300
>     > (1 row)
>     >
>     > And thus thought of supporting those.
>     > Do we want this JSON item method to behave differently here?
>
>     Ok, it would make sense to support this in SQL/JSON as well.
>
>
> OK. So with this, we don't need changes done in your 0001 patches.
>
>
>     > I will merge them all into one and will try to keep them in the
>     order
>     > specified in sql_features.txt.
>     > However, for documentation, it makes more sense to keep them in
>     logical
>     > order than the alphabetical one. What are your views on this?
>
>     The documentation can be in a different order.
>
>
> Thanks, Andrew and Peter for the confirmation.
>
> Attached merged single patch along these lines.


Thanks, I have pushed this.


cheers


andrew


--
Andrew Dunstan
EDB:https://www.enterprisedb.com