SQL/JSON documentation JSON_TABLE

Поиск
Список
Период
Сортировка
От Erik Rijkers
Тема SQL/JSON documentation JSON_TABLE
Дата
Msg-id 7bb38ff6-c4ef-5c5d-4645-185b4ad3d094@xs4all.nl
обсуждение исходный текст
Ответы Re: SQL/JSON documentation JSON_TABLE  (Andrew Dunstan <andrew@dunslane.net>)
Список 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



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: replacing role-level NOINHERIT with a grant-level option
Следующее
От: Tom Lane
Дата:
Сообщение: Re: automatically generating node support functions