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

Hi

> A main concern among most (all?) participants of the thread, regardless of
> format supported, is that quoting is hard and must be done right for all
> object
> names postgres support (including any not currently in scope by this
> patch).
>
>
Just a small note - when quoting is calculated to design, then the
implementation is easy. I am sure, so my last code covers all
possibilities, and it is about 100 lines of code.

> Below is an attempt at summarizing and grouping the proposals so far into
> the
> set of ideas presented:
>
> A) A keyword+object based format to invoke with a switch to essentially
> allow for more filters than the commandline can handle and nothing
> more.
> After a set of revisions, the current proposal is:
> [include|exclude] [<objtype>] [<objident>]
>
> B) A format similar to (A) which can also be used for pg_dump
> configuration
>
> C) The format in (A), or a close variant thereof, with the intention
> of it
> being included in/referred to from a future configuration file of
> currently
> unknown format. One reference being a .gitignore type file.
>
> D) An existing format (JSON and TOML have been suggested, with JSON
> being dismissed due to lack of comment support) which has quoting
> conventions that supports postgres' object names and which can be used
> to
> define a full pg_dump configuration file syntax.
>
> For B), C) and D) there is implicit consensus in the thread that we don't
> need
> to implement the full configuration file as of this patch, merely that it
> *must* be possible to do so without having to paint ourselves out of a
> corner.
>
> At this point it seems to me that B) and C) has the broadest support. Can
> the
> C) option may represent the compromise between "simple" format for object
> filtering and a more structured format for configuration? Are there other
> options?
>

What should be a benefit of this variant?

Regards

Pavel

>
> Thoughts?
>
> --
> Daniel Gustafsson https://vmware.com/
>
> [0] https://postgr.es/m/F6674FF0-5800-4AED-9DC7-13C475707241@yesql.se
> [1]
> https://postgr.es/m/CALAY4q9u30L7oGhbsfY3dPECQ8SrYa8YO=H-xOn5xWUeiEneeg@mail.gmail.com
> [2] https://postgr.es/m/20201110200904.GU16415@tamriel.snowman.net
> [3]
> https://postgr.es/m/CAEZATCVKMG7+b+_5tNwrNZ-aNDBy3=FMRNea2bO9O4qGcEvSTg@mail.gmail.com
> [4] https://postgr.es/m/502641.1606334432@sss.pgh.pa.us
> [5] https://postgr.es/m/619671.1606406538@sss.pgh.pa.us
> [6]
> https://postgr.es/m/cb545d78-2dae-8d27-f062-822a07ca56cf@enterprisedb.com
> [7] https://postgr.es/m/202107122259.n6o5uwb5erza@alvherre.pgsql
> [8] https://postgr.es/m/3183720.1626131795@sss.pgh.pa.us
>
>