Re: Wanted: jsonb on-disk representation documentation - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Wanted: jsonb on-disk representation documentation
Date
Msg-id CAM3SWZScGmz4jrya_qnVBQ_7EXfPwz3u5ONSEBdP5=D=Yf5KyQ@mail.gmail.com
Whole thread Raw
In response to Re: Wanted: jsonb on-disk representation documentation  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Tue, May 6, 2014 at 5:13 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> If you think the following is a solution of essential complexity in
> *new* code for navigating one level down a relatively simple *new*
> datastructure - then we have a disconnect that's larger than I am
> willing to argue about

You omitted the 40 lines of comments above the function.

> I can live with the argument that this code is what we have; but calling
> this only having the "essential complexity" is absurd.

I did not say that it only had essential complexity; just that your
criticism was vague. What's wrong with this particular code,
precisely? What complexity is incidental? Why?

I think what you're missing here is that
findJsonbValueFromSuperHeader() is useful for testing "existence" -
that's mostly what it does (serve as a worker function for the 3
existence-type operators). It's also used once to do a binary search
for a key when testing containment, ahead of testing a corresponding
value in a pair (a pair within a rhs that we're testing for
containment within an lhs "this" value).  Finally, it's also used once
with arrays when testing containment.

Why do I just match the key within findJsonbValueFromSuperHeader() for
objects, and not the key/value pair you ask? Because that's not what
existence is, and it's easier and clearer to have containment of
nested objects and arrays handling by the higher level containment
function (once we find the value from the pair, to pass back to it).
There is a number of things in tension here. A further factor is the
desire to avoid redundant code. Now, I guess you could make the case
that the handling of the JB_ARRAY and JB_OBJECT cases could be broken
out, but that isn't obviously true, since that creates redundancy for
the majority of callers that only care about existence.

If you're suggesting that the JB_ARRAY and JB_OBJECT cases within that
function are redundant, well, they're not; I'm iterating element-wise
for the former and pairwise for the latter. I'm also returning the
value for the former, and the element (which in a certain sense is
equivalent -- the equivalent of an object/pair "value") for the
latter. Note the user-visible definition of existence if you don't
know what I mean.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: tests for client programs
Next
From: Andres Freund
Date:
Subject: Re: tests for client programs