| 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: | Whole Thread | Raw Message | 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 |