Thread
Commits
-
jsonapi: Use const char *
- 15cd9a3881b0 17.0 landed
-
jsonapi: Use size_t
- 0b06bf9fa972 17.0 landed
-
parse_manifest: Use const char *
- 02bbc3c83aec 17.0 landed
-
jsonapi type fixups
Peter Eisentraut <peter@eisentraut.org> — 2024-06-18T11:48:17Z
I have this patch series that fixes up the types of the new incremental JSON API a bit. Specifically, it uses "const" throughout so that the top-level entry points such as pg_parse_json_incremental() can declare their arguments as const char * instead of just char *. This just works, it doesn't require any new casting tricks. In fact, it removes a few unconstify() calls. Also, a few arguments and variables that relate to object sizes should be size_t rather than int. At this point, this mainly makes the API better self-documenting. I don't think it actually works to parse larger than 2 GB chunks (not tested).
-
Re: jsonapi type fixups
Andrew Dunstan <andrew@dunslane.net> — 2024-06-20T12:05:14Z
On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote: > I have this patch series that fixes up the types of the new > incremental JSON API a bit. Specifically, it uses "const" throughout > so that the top-level entry points such as pg_parse_json_incremental() > can declare their arguments as const char * instead of just char *. > This just works, it doesn't require any new casting tricks. In fact, > it removes a few unconstify() calls. > > Also, a few arguments and variables that relate to object sizes should > be size_t rather than int. At this point, this mainly makes the API > better self-documenting. I don't think it actually works to parse > larger than 2 GB chunks (not tested). I think this is mostly OK. The change at line 1857 of jsonapi.c looks dubious, though. The pointer variable p looks anything but constant. Perhaps I'm misunderstanding. It would also be nice to reword the comment at line 3142 of jsonfuncs.c, so it can still fit on one line. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
-
Re: jsonapi type fixups
Andrew Dunstan <andrew@dunslane.net> — 2024-06-20T12:44:52Z
On 2024-06-20 Th 8:05 AM, Andrew Dunstan wrote: > > On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote: >> I have this patch series that fixes up the types of the new >> incremental JSON API a bit. Specifically, it uses "const" throughout >> so that the top-level entry points such as >> pg_parse_json_incremental() can declare their arguments as const char >> * instead of just char *. This just works, it doesn't require any >> new casting tricks. In fact, it removes a few unconstify() calls. >> >> Also, a few arguments and variables that relate to object sizes >> should be size_t rather than int. At this point, this mainly makes >> the API better self-documenting. I don't think it actually works to >> parse larger than 2 GB chunks (not tested). > > > > I think this is mostly OK. > > The change at line 1857 of jsonapi.c looks dubious, though. The > pointer variable p looks anything but constant. Perhaps I'm > misunderstanding. Ignore this comment, moment of brain fade. Of course it's the string that's constant, not the pointer. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
-
Re: jsonapi type fixups
Peter Eisentraut <peter@eisentraut.org> — 2024-06-21T06:01:11Z
On 20.06.24 14:05, Andrew Dunstan wrote: > On 2024-06-18 Tu 7:48 AM, Peter Eisentraut wrote: >> I have this patch series that fixes up the types of the new >> incremental JSON API a bit. Specifically, it uses "const" throughout >> so that the top-level entry points such as pg_parse_json_incremental() >> can declare their arguments as const char * instead of just char *. >> This just works, it doesn't require any new casting tricks. In fact, >> it removes a few unconstify() calls. >> >> Also, a few arguments and variables that relate to object sizes should >> be size_t rather than int. At this point, this mainly makes the API >> better self-documenting. I don't think it actually works to parse >> larger than 2 GB chunks (not tested). > I think this is mostly OK. > It would also be nice to reword the comment at line 3142 of jsonfuncs.c, > so it can still fit on one line. Agreed. Committed with that fixup.