Re: proposal: possibility to read dumped table's name from file

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: possibility to read dumped table's name from file
Date: 2020-07-13 14:57:41
Message-ID: 06123ECB-ED9F-40FB-BE71-8EA601B03AB5@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 13 Jul 2020, at 13:02, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

> I like JSON format. But why here? For this purpose the JSON is over engineered.

I respectfully disagree, JSON is a commonly used and known format in systems
administration and most importantly: we already have code to parse it in the
frontend.

> This input file has no nested structure - it is just a stream of lines.

Well, it has a set of object types which in turn have objects. There is more
structure than meets the eye.

Also, the current patch allows arbitrary whitespace before object names, but no
whitespace before comments etc. Using something where the rules of parsing are
known is rarely a bad thing.

> I don't think so introducing JSON here can be a good idea.

Quite possibly it isn't, but not discussing options seems like a worse idea so
I wanted to bring it up.

> It is a really different case than pg_dump manifest file - in this case, in this case pg_dump is consument.

Right, as I said these are two different, while tangentially related, things.

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-07-13 14:58:03 Re: [PATCH] Performance Improvement For Copy From Binary Files
Previous Message Fabrízio de Royes Mello 2020-07-13 14:52:23 Re: pg_dump bug for extension owned tables