Re: proposal: possibility to read dumped table's name from file

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: possibility to read dumped table's name from file
Дата
Msg-id CAFj8pRBZSLpS179BKwx8hYoXMOikk3Y10CWq5DUnbLS1Q9kYiw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: possibility to read dumped table's name from file  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: proposal: possibility to read dumped table's name from file  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers


po 13. 7. 2020 v 12:04 odesílatel Daniel Gustafsson <daniel@yesql.se> napsal:
> 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.

I like JSON format. But why here? For this purpose the JSON is over engineered. This input file has  no nested structure - it is just a stream of lines.

I don't think so introducing JSON here can be a good idea. For this feature typical usage can be used in pipe, and the most simple format (what is possible) is ideal.

It is a really different case than pg_dump manifest file - in this case, in this case pg_dump is consument.

Regards

Pavel




cheers ./daniel

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: INSERT INTO SELECT, Why Parallelism is not selected?
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Global snapshots