Re: backup manifests

From: David Steele <david(at)pgmasters(dot)net>
To: David Fetter <david(at)fetter(dot)org>, Tels <nospam-pg-abuse(at)bloodgate(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Suraj Kharage <suraj(dot)kharage(at)enterprisedb(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: backup manifests
Date: 2020-01-01 02:16:53
Message-ID: 7cb79c9e-8377-b2b5-3fa4-9775e1aca1fe@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/31/19 10:43 AM, David Fetter wrote:
> On Tue, Dec 31, 2019 at 01:30:01PM +0100, Tels wrote:
>> Moin,
>>
>> sorry for the very late reply. There was a discussion about the specific
>> format of the backup manifests, and maybe that was already discussed and I
>> just overlooked it:
>>
>> 1) Why invent your own format, and not just use a machine-readable format
>> that already exists? It doesn't have to be full blown XML, or even JSON,
>> something simple as YAML would already be better. That way not everyone has
>> to write their own parser. Or maybe it is already YAML and just the
>> different keywords where under discussion?
>
> YAML is extremely fragile and error-prone. It's also a superset of
> JSON, so I don't understand what you mean by "as simple as."
>
> -1 from me on YAML

-1 from me as well. YAML is easy to write but definitely non-trivial to
read.

> That said, I agree that there's no reason to come up with a bespoke
> format and parser when JSON is already available in every PostgreSQL
> installation. Imposing a structure atop that includes a version
> number, as you suggest, seems pretty straightforward, and should be
> done.

+1. I continue to support a format that would be easily readable
without writing a lot of code.

--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2020-01-01 02:46:11 TRUNCATE on foreign tables
Previous Message Tom Lane 2019-12-31 21:53:17 Re: Decade indication