Re: pgsql: Add more SQL/JSON constructor functions

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Amit Langote <amitlan(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add more SQL/JSON constructor functions
Date: 2024-05-28 12:41:54
Message-ID: CAKFQuwYFaXRcJLb5CkcFHYrwqMCQX2+zPJTQUN1nodHb0DriJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday, May 27, 2024, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:

> On 2024-May-27, Alvaro Herrera wrote:
>
> > > JSON_SERIALIZE()
>
> I just noticed this behavior, which looks like a bug to me:
>
> select json_serialize('{"a":1, "a":2}' returning varchar(5));
> json_serialize
> ────────────────
> {"a":
>
> I think this function should throw an error if the destination type
> doesn't have room for the output json. Otherwise, what good is the
> serialization function?
>
>
It’s not a self-evident bug given that this is exactly how casting data to
varchar(n) behaves as directed by the SQL Standard.

I'd probably leave the internal consistency and take the opportunity to
educate the reader that text is the preferred type in PostgreSQL and,
especially here, there is little good reason to use anything else.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2024-05-28 14:38:53 Re: commitfest.postgresql.org is no longer fit for purpose
Previous Message Long Song 2024-05-28 12:15:59 Re:[PATCH]A minor improvement to the error-report in SimpleLruWriteAll()