From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>
cc: Aleksander Alekseev <a.alekseev@postgrespro.ru>,
        Michael Paquier <michael.paquier@gmail.com>,
        PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: PATCH: recursive json_populate_record()
In-reply-to: <295ad4a5-2923-1834-5140-35d0b9a5818c@postgrespro.ru>
References: <222c7cfb-73c8-a56e-7844-3dc51682760d@postgrespro.ru>
 <CAB7nPqR_su1w5yC2KMSuH=XmmY8JHL+aDz-sJzc3Ln-juOAgtQ@mail.gmail.com>
 <20161227131541.GA6976@e733.localdomain>
 <1b72a62e-fd94-fd6d-c573-870af0c8600d@postgrespro.ru>
 <11489.1483901523@sss.pgh.pa.us>
 <687e19a7-14e2-d0f5-2bff-35d62bc5c05a@postgrespro.ru>
 <934.1485111512@sss.pgh.pa.us>
 <9e21a39c-c1d7-b9b5-44a0-c5345a5029f6@postgrespro.ru>
 <13020.1485377905@sss.pgh.pa.us>
 <295ad4a5-2923-1834-5140-35d0b9a5818c@postgrespro.ru>
Comments: In-reply-to Nikita Glukhov <n.gluhov@postgrespro.ru>
	message dated "Thu, 26 Jan 2017 00:36:53 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16178.1485380983.1@sss.pgh.pa.us>
Date: Wed, 25 Jan 2017 16:49:43 -0500
Message-ID: <16179.1485380983@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Nikita Glukhov <n.gluhov@postgrespro.ru> writes:
> On 25.01.2017 23:58, Tom Lane wrote:
>> I think you need to take a second look at the code you're producing
>> and realize that it's not so clean either.  This extract from
>> populate_record_field, for example, is pretty horrid:

> But what if we introduce some helper macros like this:

> #define JsValueIsNull(jsv) \
>      ((jsv)->is_json ? !(jsv)->val.json.str \
>          : !(jsv)->val.jsonb || (jsv)->val.jsonb->type == jbvNull)

> #define JsValueIsString(jsv) \
>      ((jsv)->is_json ? (jsv)->val.json.type == JSON_TOKEN_STRING \
>          : (jsv)->val.jsonb && (jsv)->val.jsonb->type == jbvString)

Yeah, I was wondering about that too.  I'm not sure that you can make
a reasonable set of helper macros that will fix this, but if you want
to try, go for it.

BTW, just as a stylistic thing, I find "a?b:c||d" unreadable: I have
to go back to the manual every darn time to convince myself whether
that means (a?b:c)||d or a?b:(c||d).  It's better not to rely on
the reader (... or the author) having memorized C's precedence rules
in quite that much detail.  Extra parens help.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers