Re: proposal: possibility to read dumped table's name from file
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>,
Justin Pryzby <pryzby@telsasoft.com>, Dean Rasheed <dean.a.rasheed@gmail.com>, Stephen Frost <sfrost@snowman.net>, Surafel Temesgen <surafel3000@gmail.com>, vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-09-17T11:42:55Z
Lists: pgsql-hackers
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 > >
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix array subscript warnings
- 17935e1fdf0a 17.0 landed
-
Read include/exclude commands for dump/restore from file
- a5cf808be55b 17.0 landed
-
Allow records to span multiple lines in pg_hba.conf and pg_ident.conf.
- 8f8154a503c7 14.0 cited