Re: backup manifests
От | David Steele |
---|---|
Тема | Re: backup manifests |
Дата | |
Msg-id | 1115c3d4-2d80-8388-4fd4-5fdb3ee9b429@pgmasters.net обсуждение исходный текст |
Ответ на | Re: backup manifests (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: backup manifests
|
Список | pgsql-hackers |
Hi Stephen, On 1/14/20 1:35 PM, Stephen Frost wrote: > > My thought, which I had expressed to David (though he obviously didn't > entirely agree with me since he suggested the other options), was to > adapt the pgBackRest JSON parser, which isn't really all that much code. It's not that I didn't agree, it's just that the pgBackRest code does use mem contexts, the type system, etc. After looking at some other solutions with similar amounts of code I thought they might be more acceptable. At least it seemed like a good idea to throw it out there. > Even so, David's offered to adjust the code to use the frontend's memory > management (*cough* malloc()..), and error handling/logging, and he had > some idea for Variadics (or maybe just pulling the backend's Datum > system in..? He could answer better), and basically write a frontend > JSON parser for PG without too much code, no external dependencies, and > to make sure it answers this requirement, and I've agreed that he can > spend some time on that instead of pgBackRest to get us through this, if > everyone else is agreeable to the idea. To keep it simple I think we are left with callbacks or a somewhat static "what's the next datum" kind of approach. I think the latter could get us through a release or two while we make improvements. > Obviously this isn't intended > to box anyone in- if there turns out even after the code's been written > to be some fatal issue with using it, so be it, but we're offering to > help. I'm happy to work up a prototype unless the consensus is that we absolutely don't want a second JSON parser in core. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: