Re: making the backend's json parser work in frontend code
От | Robert Haas |
---|---|
Тема | Re: making the backend's json parser work in frontend code |
Дата | |
Msg-id | CA+TgmoYw5_VMggwa+ima1wDJ-UY2y+GVT506D4ya1fwybDvEWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: making the backend's json parser work in frontend code (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: making the backend's json parser work in frontend code
|
Список | pgsql-hackers |
On Thu, Jan 23, 2020 at 1:05 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > Ok, I finished merging with Robert’s patches. The attached follow his numbering, with my patches intended to by appliedafter his. I think it'd be a good idea to move the pg_wchar.h stuff into a new thread. This thread is getting a bit complicated, because we've got (1) the patches need to do $SUBJECT plus (2) additional patches that clean up the multibyte stuff more plus (3) discussion of issues that pertain to the backup manifest thread. To my knowledge, $SUBJECT doesn't strictly require the pg_wchar.h changes, so I suggest we try to segregate those. > I tried not to change his work too much, but I did a bit of refactoring in 0010, as explained in the commit comment. Hmm, I generally prefer to avoid these kinds of macro tricks because I think they can be confusing to the reader. It's worth it in a case like equalfuncs.c where so much boilerplate code is saved that the gain in readability more than makes up for having to go check what the macros do -- but I don't feel that's the case here. There aren't *that* many call sites, and I think the code will be easier to understand without "return" statements concealed within macros... > I ran some benchmarks for json parsing in the backend both before and after these patches, with very slight changes inruntime. Cool, thanks. Since 0001-0003 have been reviewed by multiple people and nobody's objected, I have committed those. But I made a hash of it: the first one, I failed to credit any reviewers, or include a Discussion link, and I just realized that I should have listed Alvaro's name as a reviewer also. Sorry about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: