Re: pgsql: Add more SQL/JSON constructor functions - Mailing list pgsql-hackers

From Amit Langote
Subject Re: pgsql: Add more SQL/JSON constructor functions
Date
Msg-id CA+HiwqHCGuzp-v2a6qbJZiDD1wdXay_a_H_fnFs5y25aEbzEkw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Add more SQL/JSON constructor functions  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: pgsql: Add more SQL/JSON constructor functions
List pgsql-hackers
On Tue, Jun 4, 2024 at 7:03 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Tue, Jun 4, 2024 at 2:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Peter Eisentraut <peter@eisentraut.org> writes:
> > > On 02.06.24 21:46, Tom Lane wrote:
> > >> If you don't
> > >> like our current behavior, then either you have to say that RETURNING
> > >> with a length-limited target type is illegal (which is problematic
> > >> for the spec, since they have no such type) or that the cast behaves
> > >> like an implicit cast, with errors for overlength input (which I find
> > >> to be an unintuitive definition for a construct that names the target
> > >> type explicitly).
> >
> > > It asks for the latter behavior, essentially (but it's not defined in
> > > terms of casts).  It says:
> >
> > Meh.  Who needs consistency?  But I guess the answer is to do what was
> > suggested earlier and change the code to use COERCE_IMPLICIT_CAST.
>
> OK, will post a patch to do so in a new thread on -hackers.

Oops, didn't realize that this is already on -hackers.

Attached is a patch to use COERCE_IMPLICIT_CAST when the RETURNING
type specifies a length limit.

Given that this also affects JSON_OBJECT() et al that got added in
v16, maybe back-patching is in order but I'd like to hear opinions on
that.


--
Thanks, Amit Langote

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Backup and Restore of Partitioned Table in PG-15
Next
From: Matthias van de Meent
Date:
Subject: Re: [PATCH] Improve error message when trying to lock virtual tuple.