Re: proposal: possibility to read dumped table's name from file
От | Justin Pryzby |
---|---|
Тема | Re: proposal: possibility to read dumped table's name from file |
Дата | |
Msg-id | 20200713143204.GE23581@telsasoft.com обсуждение исходный текст |
Ответ на | Re: proposal: possibility to read dumped table's name from file (Daniel Gustafsson <daniel@yesql.se>) |
Список | 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
В списке pgsql-hackers по дате отправления: