Re: backup manifests
От | Tom Lane |
---|---|
Тема | Re: backup manifests |
Дата | |
Msg-id | 30229.1577931611@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: backup manifests (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: backup manifests
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > AFAICS, the only options to make that work with JSON are (1) introduce > a new hand-coded JSON parser designed for frontend operation, (2) add > a dependency on an external JSON parser that we can use from frontend > code, or (3) adapt the existing JSON parser used in the backend so > that it can also be used in the frontend. > ... I'd > be willing to do (3) if somebody could explain to me how to solve the > problems with porting that code to work on the frontend side, but the > only suggestion so far as to how to do that is to port memory > contexts, elog/report, and presumably encoding handling to work on the > frontend side. That seems to me to be an unreasonably large lift, Yeah, agreed. The only consideration that'd make that a remotely sane idea is that if somebody did the work, there would be other uses for it. (One that comes to mind immediately is cleaning up ecpg's miserably-maintained fork of the backend datetime code.) But there's no denying that it would be a large amount of work (if it's even feasible), and nobody has stepped up to volunteer. It's not reasonable to hold up this particular feature waiting for that to happen. If a tab-delimited file can handle this requirement, that seems like a sane choice to me. regards, tom lane
В списке pgsql-hackers по дате отправления: