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

po 13. 7. 2020 v 12:04 odesílatel Daniel Gustafsson <daniel(at)yesql(dot)se>
napsal:

> > On 13 Jul 2020, at 10:20, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> > attached updated patch
>
> Sorry for jumping in late, but thinking about this extension to pg_dump:
> doesn't it make more sense to use an existing file format like JSON for
> this,
> given that virtually all devops/cd/etc tooling know about JSON already?
>
> Considering its application and the problem space, I'd expect users to
> generate
> this file rather than handcraft it with 10 rows of content, and standard
> file
> formats help there. Creative users could even use the database itself to
> easily manage its content and generate the file (which isn't limited to
> JSON of
> course, but it would be easier). Also, we now have backup manifests in
> JSON
> which IMO sets a bit of a precedent, even though thats a separate thing.
>
> At the very least it seems limiting to not include a file format version
> identifier since we'd otherwise risk running into backwards compat issues
> should we want to expand on this in the future.
>

I like JSON format. But why here? For this purpose the JSON is over
engineered. This input file has no nested structure - it is just a stream
of lines.

I don't think so introducing JSON here can be a good idea. For this feature
typical usage can be used in pipe, and the most simple format (what is
possible) is ideal.

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

Regards

Pavel

> cheers ./daniel
>
>