On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack <jcflack@acm.org> wrote: > > Hi, > > On 06/17/24 02:43, Amit Langote wrote: > > <replaceable>context_item</replaceable> expression can be a value of > > any type that can be cast to <type>jsonb</type>. This includes types > > such as <type>char</type>, <type>text</type>, <type>bpchar</type>, > > <type>character varying</type>, and <type>bytea</type> (with > > <code>ENCODING UTF8</code>), as well as any domains over these types. > > Reading this message in conjunction with [0] makes me think that we are > really talking about a function that takes a first parameter of type jsonb, > and behaves exactly that way (so any cast required is applied by the system > ahead of the call). Under those conditions, this seems like an unusual > sentence to add in the docs, at least until we have also documented that > tan's argument can be of any type that can be cast to double precision. >
I guess it would be fine to add an unusual sentence to the docs.
imagine a function: array_avg(anyarray) returns anyelement. array_avg calculate an array's elements's avg. like array('{1,2,3}'::int[]) returns 2. but array_avg won't make sense if the input argument is a date array. so mentioning in the doc: array_avg can accept anyarray, but anyarray cannot date array. seems ok.
There is existing wording for this:
"The expression can be of any JSON type, any character string type, or bytea in UTF8 encoding."
If you add this sentence to the paragraph the link that already exists, which simply points the reader to this sentence, becomes redundant and should be removed.
As for table 9.16.3 - it is unwieldy already. Lets try and make the core syntax shorter, not longer. We already have precedence in the subsequent json_table section - give each major clause item a name then below the table define the syntax and meaning for those names. Unlike in that section - which probably should be modified too - context_item should have its own description line.
