Re: proposal: possibility to read dumped table's name from file
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
Stephen Frost <sfrost@snowman.net>,
Surafel Temesgen <surafel3000@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
vignesh C <vignesh21@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Daniel Gustafsson <daniel@yesql.se>
Date: 2020-11-26T16:02:18Z
Lists: pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > Actually, that raises a different possible benefit of passing options > in an options file -- if the user wants to pass in a table name > pattern, it can be a nuisance if the shell's argument processing does > additional unwanted things like globbing and environment variable > substitutions. Using an options file could provide a handy way to > ensure that any option values are interpreted exactly as written, > without any additional mangling. Huh? Any format we might devise, or borrow, will have to have some kind of escaping/quoting convention. The idea that "we don't need that" tends to lead to very ugly workarounds later. I do agree that the shell's quoting conventions are pretty messy and so those aren't the ones we should borrow. We could do a lot worse than to use some established data format like JSON or YAML. Given that we already have src/common/jsonapi.c, it seems like JSON would be the better choice of those two. regards, tom lane
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