Re: proposal: possibility to read dumped table's name from file
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, vignesh C <vignesh21@gmail.com>, pgsql-hackers@postgresql.org
Date: 2020-07-13T14:32:04Z
Lists: pgsql-hackers
On Mon, Jul 13, 2020 at 12:04:09PM +0200, Daniel Gustafsson wrote: > 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. I mentioned having tested this patch as we would use it. But it's likely I *wouldn't* use it if the format was something which required added complexity to pipe in from an existing shell script. > 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. Maybe .. I'm not sure. The patch would of course be extended to handle additional include/exclude options. Is there any other future behavior we might reasonably anticipate ? If at some point we wanted to support another file format, maybe it would look like: --format=v2:filters.txt (or maybe the old one would be v1:filters.txt) -- Justin
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