Re: pg_dump --with-* options
От | Álvaro Herrera |
---|---|
Тема | Re: pg_dump --with-* options |
Дата | |
Msg-id | 202507300823.e4fwfr5vorka@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg_dump --with-* options (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: pg_dump --with-* options
|
Список | pgsql-hackers |
On 2025-Jun-25, Fujii Masao wrote: > For the record, my vote is: default "off" for pg_dump and pg_dumpall, > and "on" for pg_restore. I don't know if this horse is already dead, so bear with me while I beat it a little more. > [...] we could simplify further: > > * Keep: --schema-only, --data-only, --statistics-only, and --statistics > * Remove: --no-schema, --no-data, --no-statistics, --with-schema, and --with-data > * Combinations: > Schema + Data + Stats : --statistics > Schema + Data : (default) > Schema + Stats : --schema-only --statistics > Data + Stats : --data-only --statistics > Schema only : --schema-only > Data only : --data-only > Stats only : --statistics-only I think combinatorial explosions of options is not a great situation to be in, particularly if we have to make endless decisions on which combinations are valid or sensible. Maybe we should invent a new switch, something like --include=[schema,data,statistics] with which users can give one or more comma-separated types to be included in the dump. Then we state that --data-only is synonym for --include=data and --schema-only is synonym for --include=schema, and we don't need any other switches. Then it is obvious what happens, how to combine object types in the dumps and restores, and there's no need to reject invalid combinations because there aren't any. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun)
В списке pgsql-hackers по дате отправления: