Re: [HACKERS] PATCH: recursive json_populate_record()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] PATCH: recursive json_populate_record()
Дата
Msg-id 16179.1485380983@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] PATCH: recursive json_populate_record()  (Nikita Glukhov <n.gluhov@postgrespro.ru>)
Ответы Re: [HACKERS] PATCH: recursive json_populate_record()  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] multivariate statistics (v19)
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] patch: function xmltable