Horton

Re: More new SQL/JSON item methods

Chapman Flack <chap@anastigmatix.net>

View thread
From: Chapman Flack <chap@anastigmatix.net>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Jeevan Chalke <jeevan.chalke@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-08-30T17:20:49Z
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 →

  1. Rationalize and improve error messages for some jsonpath items

  2. Clean up a bug in sql/json items commit 66ea94e8e6

  3. Implement various jsonpath methods

  4. Reorganise jsonpath operators and methods

  5. Add numeric_int8_opt_error() to optionally suppress errors

On 2023-08-30 12:28, Alvaro Herrera wrote:
> Yeah, I think the experience of the SQL committee with XML was pretty
> bad, as you carefully documented.  I hope they don't make such a mess
> with JSON.

I guess the SQL committee was taken by surprise after basing something
on Infoset and XPath 1.0 for 2003, and then w3 deciding those things
needed to be scrapped and redone with the lessons learned. So the
SQL committee had to come out with a rather different SQL/XML for 2006,
but I'd say the 2003-2006 difference is the only real 'mess', and other
than going back in time to unpublish 2003, I'm not sure how they'd have
done better.

>         b) Otherwise, the result of JAE is the SQL/JSON sequence V_1,
>            ..., V_n.

This has my Spidey sense tingling, as it seems very parallel to SQL/XML
where the result of XMLQUERY is to have type XML(SEQUENCE), which is a
type we do not have, and I'm not sure we have a type for "JSON sequence"
either, unless SQL/JSON makes it equivalent to a JSON array (which
I guess is conceivable, more easily than with XML). What does SQL/JSON
say about this SQL/JSON sequence type and how it should behave?

Regards,
-Chap