SQL/JSON documentation JSON_TABLE

From: Erik Rijkers <er(at)xs4all(dot)nl>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: SQL/JSON documentation JSON_TABLE
Date: 2022-07-08 20:03:00
Message-ID: 7bb38ff6-c4ef-5c5d-4645-185b4ad3d094@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Attached are a few small changes to the JSON_TABLE section in func.sgml.

The first two changes are simple typos.

Then there was this line:

----
context_item, path_expression [ AS json_path_name ] [ PASSING { value AS
varname } [, ...]]
----

those are the parameters to JSON_TABLE() so I changed that line to:

----
JSON_TABLE(context_item, path_expression [ AS json_path_name ] [ PASSING
{ value AS varname } [, ...]])
----

Some parts of the JSON_TABLE text strike me as opaque. For instance,
there are paragraphs that more than once use the term:
json_api_common_syntax

'json_api_common_syntax' is not explained. It turns out it's a relic
from Nikita's original docs. I dug up a 2018 patch where the term is
used as:

---- 2018:
JSON_TABLE (
json_api_common_syntax [ AS path_name ]
COLUMNS ( json_table_column [, ...] )
(etc...)
----

with explanation:

---- 2018:
json_api_common_syntax:
The input data to query, the JSON path expression defining the
query, and an optional PASSING clause.
----

So that made sense then (input+jsonpath+params=api), but it doesn't now
fit as such in the current docs.

I think it would be best to remove all uses of that compound term, and
rewrite the explanations using only the current parameter names
(context_item, path_expression, etc).

But I wasn't sure and I haven't done any such changes in the attached.

Perhaps I'll give it a try during the weekend.

Erik Rijkers

Attachment Content-Type Size
func.sgml.20220708.diff text/x-patch 2.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-08 20:03:45 Re: automatically generating node support functions
Previous Message Robert Haas 2022-07-08 19:56:56 Re: replacing role-level NOINHERIT with a grant-level option