Обсуждение: Schizophrenic coding in gin_extract_jsonb(_hash)
Would someone care to defend this code?
int total = 2 * JB_ROOT_COUNT(jb);
...
if (total == 0) { *nentries = 0; PG_RETURN_POINTER(NULL); }
...
while ((r = JsonbIteratorNext(&it, &v, false)) != WJB_DONE) { if (i >= total) { total *= 2;
entries = (Datum *) repalloc(entries, sizeof(Datum) * total); }
The early-exit code path supposes that JB_ROOT_COUNT is absolutely
reliable as an indicator that there's nothing in the jsonb value.
On the other hand, the realloc logic inside the iteration loop implies
that JB_ROOT_COUNT is just an untrustworthy estimate. Which theory is
correct? And why is there not a comment to be seen anywhere? If the code
is correct then this logic is certainly worthy of a comment or three.
regards, tom lane
On Tue, May 6, 2014 at 8:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The early-exit code path supposes that JB_ROOT_COUNT is absolutely > reliable as an indicator that there's nothing in the jsonb value. > On the other hand, the realloc logic inside the iteration loop implies > that JB_ROOT_COUNT is just an untrustworthy estimate. Which theory is > correct? And why is there not a comment to be seen anywhere? If the code > is correct then this logic is certainly worthy of a comment or three. JsonbIteratorNext() is passed "false" as its skipNested argument. It's recursive. -- Peter Geoghegan
Peter Geoghegan <pg@heroku.com> writes:
> On Tue, May 6, 2014 at 8:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The early-exit code path supposes that JB_ROOT_COUNT is absolutely
>> reliable as an indicator that there's nothing in the jsonb value.
>> On the other hand, the realloc logic inside the iteration loop implies
>> that JB_ROOT_COUNT is just an untrustworthy estimate. Which theory is
>> correct? And why is there not a comment to be seen anywhere? If the code
>> is correct then this logic is certainly worthy of a comment or three.
> JsonbIteratorNext() is passed "false" as its skipNested argument. It's
> recursive.
And?
I think you're just proving the point that this code is woefully
underdocumented. If there were, somewhere, some comment explaining
what the heck JB_ROOT_COUNT actually counts, maybe I wouldn't be asking
this question. jsonb.h is certainly not divulging any such information.
regards, tom lane
On 05/07/2014 06:27 PM, Tom Lane wrote: > I think you're just proving the point that this code is woefully > underdocumented. If there were, somewhere, some comment explaining > what the heck JB_ROOT_COUNT actually counts, maybe I wouldn't be asking > this question. jsonb.h is certainly not divulging any such information. After having reverse-engineered the convertJsonb code, I think I can explain what JB_ROOT_COUNT is. If the root of the Jsonb datum is an array, it's the number of elements in that top-level array. If it's an object, it's the number of key/value pairs in that top-level object. Some of the elements of that array (or values of the object) can be arrays or objects themselves. gin_extract_jsonb recursively extracts all the elements, keys and values of any sub-object too, but JB_ROOT_COUNT only counts the top-level elements. (I hope this is made a bit more clear in the comments I added in the patch I posted this morning) - Heikki
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> gin_extract_jsonb recursively extracts all the elements, keys and values
> of any sub-object too, but JB_ROOT_COUNT only counts the top-level elements.
Got it. So if the top level is empty, we can exit early, but otherwise we
use its length * 2 as a guess at how big the output will be; which will
be right if it's an object without further substructure, and otherwise
might need enlargement.
> (I hope this is made a bit more clear in the comments I added in the
> patch I posted this morning)
Didn't read that yet, but will incorporate this info into the jsonb_gin
patch I'm working on.
regards, tom lane