Re: SQL/JSON query functions context_item doc entry and type requirement

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Chapman Flack <jcflack(at)acm(dot)org>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL/JSON query functions context_item doc entry and type requirement
Date: 2024-06-19 15:29:39
Message-ID: CACJufxE2VjNq2Fm1=JYe88aYwZZ8J3w3vYL2+y_2YCuC4BFCEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 17, 2024 at 9:05 PM Chapman Flack <jcflack(at)acm(dot)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.

> On the other hand, if the behavior of the functions were to be changed
> (perhaps using prosupport rewriting as suggested in [1]?) so that it was
> not purely describable as a function accepting exactly jsonb with a
> possible system-applied cast in front, then in that case such an added
> explanation in the docs might be very fitting.
>

prosupport won't work, I think.
because json_exists, json_value, json_query, json_table don't have
pg_proc entries.
These are more like expressions.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-06-19 15:34:52 Re: Better error message when --single is not the first arg to postgres executable
Previous Message Robert Haas 2024-06-19 15:28:46 Re: Extension security improvement: Add support for extensions with an owned schema