From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: David Fetter <david@fetter.org>, David Steele <david@pgmasters.net>,
        Tels <nospam-pg-abuse@bloodgate.com>,
        Suraj Kharage <suraj.kharage@enterprisedb.com>,
        Rushabh Lathia <rushabh.lathia@gmail.com>,
        Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
        Jeevan Chalke <jeevan.chalke@enterprisedb.com>,
        vignesh C <vignesh21@gmail.com>
Subject: Re: backup manifests
In-reply-to: 
 <CA+TgmoY+U30wCcxD6gLM9kFduMTGGwB1Ei06znLDqTqzcb+38A@mail.gmail.com>
References: 
 <CAF1DzPXcCgXP2awVaH4uHovPo77JdLYPAYShzwnSPMVzdUmxSQ@mail.gmail.com>
 <CA+TgmoZdJ=vBoDU1Skv52Prybp36kMvmpTDBXbmoky0owNgMiA@mail.gmail.com>
 <CAF1DzPW1CAjR7FG86b-OL+hAP2xGqmBUtv0WtRhDz+r+Mwy-Hw@mail.gmail.com>
 <CA+TgmoYY5LXfbmeCO3gpCoCJcqNj0125PO7B7ecuJjnoEdB08A@mail.gmail.com>
 <CAF1DzPXOofDsdSqgEtzpegfcvqB_1TND_h_8uQrvJuVvx-4pDA@mail.gmail.com>
 <CA+TgmobnSHW3upkS_x6D=cM9A3jT9ZA0pcH0FJitBfkyW7sFJA@mail.gmail.com>
 <f97892ef565db763c97f23566c2cb6e5@bloodgate.com>
 <20191231174325.GQ32763@fetter.org>
 <7cb79c9e-8377-b2b5-3fa4-9775e1aca1fe@pgmasters.net>
 <CA+Tgmoa+oTgwobVQFb+BGSaGLxS7_tqZJbgUP=waskfb83wvKQ@mail.gmail.com>
 <20200101190917.GR32763@fetter.org> <7437.1577925975@sss.pgh.pa.us>
 <CA+TgmoY+U30wCcxD6gLM9kFduMTGGwB1Ei06znLDqTqzcb+38A@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 01 Jan 2020 20:57:11 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30228.1577931611.1@sss.pgh.pa.us>
Date: Wed, 01 Jan 2020 21:20:11 -0500
Message-ID: <30229.1577931611@sss.pgh.pa.us>
Precedence: bulk

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