From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Subject: | Re: pg_parse_json() should not leak token copies on failure |
Date: | 2024-10-02 17:45:05 |
Message-ID: | 258d8a40-e629-43ab-86bf-6d4504255e89@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-10-01 Tu 3:04 PM, Jacob Champion wrote:
> (Tom, thank you for the fixup in 75240f65!)
>
> Off-list, Andrew suggested an alternative approach to the one I'd been
> taking: let the client choose whether it wants to take token ownership
> to begin with. v3 adds a new flag (and associated API) which will
> allow libpq to refuse ownership of those tokens. The lexer is then
> free to clean everything up during parse failures.
>
> Usually I'm not a fan of "do the right thing" flags, but in this case,
> libpq really is the outlier. And it's nice that existing clients
> (potentially including extensions) don't have to worry about an API
> change.
Yeah.
Generally looks good. Should we have a check in
setJsonLexContextOwnsTokens() that we haven't started parsing yet, for
the incremental case?
>
> At the moment, we have a test matrix consisting of "standard frontend"
> and "shlib frontend" tests for the incremental parser. I'm planning
> for the v4 patch to extend that with a "owned/not owned" dimension;
> any objections?
>
Sounds reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-10-02 18:04:08 | Re: On disable_cost |
Previous Message | Jacob Champion | 2024-10-02 17:16:53 | Re: Add support to TLS 1.3 cipher suites and curves lists |