Re: More new SQL/JSON item methods

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: More new SQL/JSON item methods
Date: 2023-08-30 17:20:49
Message-ID: 588818a001ec1ba066fa0dac079f1530@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2023-08-30 18:00:13 Replace some cstring_to_text to cstring_to_text_with_len
Previous Message Daniel Verite 2023-08-30 16:40:45 Re: EBCDIC sorting as a use case for ICU rules