Re: JSON_VALUE() behavior when RETURNING bytea (expected base64 decoding)

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Shay Rojansky <roji(at)roji(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: JSON_VALUE() behavior when RETURNING bytea (expected base64 decoding)
Date: 2025-03-06 16:03:26
Message-ID: 49537b27-6c0b-49cc-b168-361b0c9ada09@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.03.25 11:55, Shay Rojansky wrote:
> For whatever it's worth, I'll note that SQL Server's OPENJSON does do
> this (so when a JSON string property is extracted as a binary type,
> base64 encoding is assumed). Other databases also have very specific
> documented conversion rules for JSON_VALUE RETURNING (Oracle <https://
> docs.oracle.com/en/database/oracle/oracle-database/19/adjsn/clauses-
> used-in-functions-and-conditions-for-json.html#GUID-
> DE9F29D3-1C23-4271-9DCD-E585866576D2>, DB2 <https://www.ibm.com/docs/en/
> i/7.3?topic=functions-json-table#rbafzscajsontable__json_result> (table
> 1)). I'm basically trying to show that RETURNING definitely isn't a
> simple cast-from-string in other databases, but is a distinct conversion
> mechanism that takes into account the fact the the origin data comes
> from JSON.

According to the SQL standard, once you account for various special
cases (non-scalar values, null values), it comes down to a cast.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexandra Wang 2025-03-06 16:06:50 Re: NOT ENFORCED constraint feature
Previous Message Jelte Fennema-Nio 2025-03-06 16:00:52 Re: Commitfest app release on Feb 17 with many improvements