Re: How to fork pg_dump or psql w/o leaking secrets?

Поиск
Список
Период
Сортировка
От Dominique Devienne
Тема Re: How to fork pg_dump or psql w/o leaking secrets?
Дата
Msg-id CAFCRh--w5WjGtmNJH9D8uEO7SooZhQWTQTCL8e0sCoyGd-J6Tg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How to fork pg_dump or psql w/o leaking secrets?  (Luca Ferrari <fluca1978@gmail.com>)
Ответы Re: How to fork pg_dump or psql w/o leaking secrets?  (Brad White <b55white@gmail.com>)
Список pgsql-general
On Fri, Sep 22, 2023 at 5:19 PM Luca Ferrari <fluca1978@gmail.com> wrote:
On Fri, Sep 22, 2023 at 3:24 PM Dominique Devienne <ddevienne@gmail.com> wrote:
You added information I was not aware before: you are dumping
PostgreSQL to restore it into SQLite, while I was thinking you wanted
to do some stuff with a PostgreSQL-to-PostgreSQL backup and restore.

I must be really bad at explaining things today, sorry...

Because of course I'm doing PostgreSQL-to-PostgreSQL backup/restore.
The fact I use a custom SQLite DB file as the backup's "format" instead of
a "pile-of-files" (or a TAR of that pile), is the only difference.

That, and the fact it's a backup that mixes one full schema with part of another.
And that my SQLite backup format is much more convenient and "expressive" IMHO,
since fully introspectable ("semi-opaque", since rows are still COPY BINARY encoded).

Writing the backup as an SQLite DB incurs a little overhead, of course,
compared to just appending to per-table files, but not that much when
in non-transactional mode. Acceptable tradeoff compared to the fact one
can open the backup easily and see the tables and rows almost as-is,
which also opens the door to partial restores (there are separates "roots",
independent entity trees, in these schemas).

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

Предыдущее
От: Luca Ferrari
Дата:
Сообщение: Re: How to fork pg_dump or psql w/o leaking secrets?
Следующее
От: "Johnson, Bruce E - (bjohnson)"
Дата:
Сообщение: Accessing system information functions