From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: jsonapi: scary new warnings with LTO enabled |
Date: | 2025-04-22 10:10:29 |
Message-ID: | 0C92C876-09A3-483C-82C5-E26F0C1B34B5@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 21 Apr 2025, at 20:58, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> Personally, I'm fine with can't-fail APIs, as long as they're
> documented as such. (I think the deferred error API was probably
> chosen so that src/common JSON clients could be written without a lot
> of pain?)
My preference is that no operation can silently work on a failed object, but
it's not a hill (even more so given where we are in the cycle). The attached
v3 allocates via the JSON api, no specific error handling should be required as
it's already handled today.
--
Daniel Gustafsson
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Allocate-JsonLexContexts-on-the-heap-to-avoid-war.patch | application/octet-stream | 5.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Frédéric Yhuel | 2025-04-22 10:43:10 | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Previous Message | Daniel Gustafsson | 2025-04-22 10:02:42 | Re: [PoC] Federated Authn/z with OAUTHBEARER |