Re: pg_parse_json() should not leak token copies on failure

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: pg_parse_json() should not leak token copies on failure
Date: 2024-10-01 19:04:53
Message-ID: CAOYmi+=ncG2_dLvno85_8Hjgjoh49_=FDMKv4LTvvsP+P=59_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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?

Thanks,
--Jacob

Attachment Content-Type Size
v3-0001-jsonapi-add-lexer-option-to-keep-token-ownership.patch application/octet-stream 9.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2024-10-01 19:34:20 Re: Fixing backslash dot for COPY FROM...CSV
Previous Message Alexander Lakhin 2024-10-01 19:00:00 Re: query_id, pg_stat_activity, extended query protocol