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()
|
Список | 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 по дате отправления: