On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote: > No code chunks left, only a documentation patch which should land
Documentation review for a6baa4bad. > Construct a JSON the provided strings: a JSON what ? *from* the provided strings ? > Construct a JSON from the provided values various types: should say "a JSON scalar" ? *of* various types ? > Construct a JSON object from the provided key/value pairs of various types: For comparison, that one looks ok. + <function>JSON_EXISTS</function> function checks whether the provided + <function>JSON_VALUE</function> function extracts a value from the provided + <function>JSON_QUERY</function> function extracts an <acronym>SQL/JSON</acronym> + <function>JSON_TABLE</function> function queries <acronym>JSON</acronym> data + <function>JSON_TABLE</function> uses the + <function>JSON_SERIALIZE</function> function transforms a SQL/JSON value I think all these should all begin with "THE >...< function ...", like the others do. +To use other types, you must create the <literal>CAST</literal> from <type>json</type> for this type. => create a cast from json to this type. +Values can be null, but not keys. I think it's clearer to say "..but keys cannot." + For any scalar other than a number or a Boolean the text Boolean COMMA the text + The path name must be unique and cannot coincide with column names. Maybe say "name must be unique and distinct from the column names." + ... If you specify a <command>GROUP BY</command> + or an <command>ORDER BY</command> clause, this function returns a separate JSON object + for each table row. "for each table row" sounds inaccurate or imprecise. The SELECT docs say this: | GROUP BY will condense into a single row all selected rows that share the same values for the grouped expressions BTW, the documentation references look a little like OIDs... Does someone already have an SNMP-based doc browser ? | For details, see Section 9.16.3.4.2.
