Re: proposal: possibility to read dumped table's name from file
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-13T10:04:09Z
Lists: pgsql-hackers
> On 13 Jul 2020, at 10:20, Pavel Stehule <pavel.stehule@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. cheers ./daniel
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