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

2024-11-27 Thread Andrew Dunstan
On 2024-10-31 Th 5:10 PM, Jacob Champion wrote: On Mon, Oct 7, 2024 at 3:45 PM Jacob Champion wrote: I've added a 0002 as well. 0002 has since been applied [1] so I'm reattaching v4-0001 to get the cfbot happy again. --Jacob [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=41b

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

2024-10-31 Thread Jacob Champion
On Mon, Oct 7, 2024 at 3:45 PM Jacob Champion wrote: > I've added a 0002 as well. 0002 has since been applied [1] so I'm reattaching v4-0001 to get the cfbot happy again. --Jacob [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=41b023946d v4-0001-jsonapi-add-lexer-option-to-keep-

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

2024-10-07 Thread Jacob Champion
On Wed, Oct 2, 2024 at 10:45 AM Andrew Dunstan wrote: > Generally looks good. Should we have a check in > setJsonLexContextOwnsTokens() that we haven't started parsing yet, for > the incremental case? Good catch. Added in v4. > > At the moment, we have a test matrix consisting of "standard front

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

2024-10-02 Thread Andrew Dunstan
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

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

2024-10-01 Thread Jacob Champion
(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 token

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

2024-06-04 Thread Michael Paquier
On Tue, Jun 04, 2024 at 10:10:06AM -0700, Jacob Champion wrote: > On Mon, Jun 3, 2024 at 9:32 PM Kyotaro Horiguchi > wrote: >> I understand that the part enclosed in parentheses refers to the "if >> (ptr) pfree(ptr)" structure. I believe we rely on the behavior of >> free(NULL), which safely does

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

2024-06-04 Thread Jacob Champion
On Mon, Jun 3, 2024 at 9:32 PM Kyotaro Horiguchi wrote: > > Hi, Thanks for the review! > I understand that the part enclosed in parentheses refers to the "if > (ptr) pfree(ptr)" structure. I believe we rely on the behavior of > free(NULL), which safely does nothing. (I couldn't find the related

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

2024-06-03 Thread Kyotaro Horiguchi
Hi, At Fri, 24 May 2024 08:43:01 -0700, Jacob Champion wrote in > On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion > wrote: > > Attached is a draft patch to illustrate what I mean, but it's > > incomplete: it only solves the problem for scalar values. > > (Attached is a v2 of that patch; in sol

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

2024-05-24 Thread Jacob Champion
On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion wrote: > Attached is a draft patch to illustrate what I mean, but it's > incomplete: it only solves the problem for scalar values. (Attached is a v2 of that patch; in solving a frontend leak I should probably not introduce a backend segfault.) --Jac