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
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 |