On Tue, May 6, 2014 at 5:13 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers