po 13. 7. 2020 v 12:04 odesÃlatel Daniel Gustafsson <dan...@yesql.se> napsal:
> > On 13 Jul 2020, at 10:20, Pavel Stehule <pavel.steh...@gmail.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 > >
