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.
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 |