| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| 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-21 15:33:28 |
| Message-ID: | CAOYmi+=w3Q-3F=LCr9hPRhiG2HGv6sogGOJW3v9pwpoCD6wN+w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 19, 2025 at 2:15 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> Since there is no way to determine if the allocation succeeded from outside of
> the JSON api it might be better to keep the calloc and explicitly free it?
I don't think so; pg_parse_json() will error out quickly, so I don't
see much advantage to the extra code. Raw performance isn't much of a
concern for the out-of-memory case, IMO.
> (Could a JsonLexContextBroken() function be useful perhaps?)
Maybe if there's ever a client that absolutely must initialize a
context before doing a bunch of independent work? But I don't think
that's true here. (Any callers we're converting from the stack API are
going to have short-lived contexts.)
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-04-21 15:55:52 | Re: Large expressions in indexes can't be stored (non-TOASTable) |
| Previous Message | Jacob Champion | 2025-04-21 15:18:58 | Re: dispchar for oauth_client_secret |