Re: SQL/JSON: functions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Nikola Ivanov <kolioffx(at)gmail(dot)com>, Himanshu Upadhyaya <upadhyaya(dot)himanshu(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Erik Rijkers <er(at)xs4all(dot)nl>
Subject: Re: SQL/JSON: functions
Date: 2022-04-11 15:54:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2022-04-08 Fr 08:15, Andrew Dunstan wrote:
> On 4/8/22 08:02, Justin Pryzby wrote:
>> 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
> Many thanks, useful.
> I already had a couple of these items on my list but I ran out of time
> before tiredness overcame me last night.
> I'm planning on removing some of that stuff that generates the last
> complaint if I can do it without too much violence.

I have attended to most of these. I just removed the GROUP BY sentence,
I don't think it added anything useful. We already refer users to the
aggregates page.

I will deal with the structural issues soon.



Andrew Dunstan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-04-11 16:09:05 Re: SQL/JSON: functions
Previous Message Julien Rouhaud 2022-04-11 15:36:31 Re: make MaxBackends available in _PG_init