Re: making the backend's json parser work in frontend code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: making the backend's json parser work in frontend code
Date
Msg-id CA+TgmobZD+tfzK55_A_FepgML0H1LgNXCwQPQKs3qewqQToRWQ@mail.gmail.com
Whole thread Raw
In response to Re: making the backend's json parser work in frontend code  (David Steele <david@pgmasters.net>)
Responses Re: making the backend's json parser work in frontend code
List pgsql-hackers
On Thu, Jan 16, 2020 at 1:58 PM David Steele <david@pgmasters.net> wrote:
> To do page-level incrementals (which this feature is intended to enable)
> the user will need to be able to associate full and incremental backups
> and the only way I see to do that (currently) is to read the manifests,
> since the prior backup should be stored there.  I think this means that
> parsing the manifest is not really optional -- it will be required to do
> any kind of automation with incrementals.

My current belief is that enabling incremental backup will require
extending the manifest format either not at all or by adding one
additional line with some LSN info.

If we could foresee a need to store a bunch of additional *per-file*
details, I'd be a lot more receptive to the argument that we ought to
be using a more structured format like JSON. And it doesn't seem
impossible that such a thing could happen, but I don't think it's at
all clear that it actually will happen, or that it will happen soon
enough that we ought to be worrying about it now.

It's possible that we're chasing a real problem here, and if there's
something we can agree on and get done I'd rather do that than argue,
but I am still quite suspicious that there's no actually serious
technical problem here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: our checks for read-only queries are not great
Next
From: Tomas Vondra
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option