Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.

Поиск
Список
Период
Сортировка
От Oleksandr Shulgin
Тема Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.
Дата
Msg-id CACACo5RkD8y4B=H7y409c3jK+oAnd57o0et9r_F8pMrs8OyJiQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.  (tutiluren@tutanota.com)
Список pgsql-bugs
Дерево обсуждения
On Tue, Jul 28, 2020 at 1:15 AM <tutiluren@tutanota.com> wrote:
Ten years ago my first reaction would be to download msys and try the command there.  It looks, however, that the development stalled around 2008: http://www.mingw.org/wiki/MSYS
Now I read that a second generation of that is available, but haven't tried it: https://www.msys2.org/

You'll have to quote the special characters differently, but that way of quoting will be familiar to the majority of folks here, I guess.
I don't want to download or install anything. I thought I would finally convince you all when I showed that my own script is fully able to receive the Unicode characters and quotes from the cmd.exe which doesn't even use the /U flag, so clearly pg_dump is not reading this correctly? I can't see any other explanation at this point. It frankly feels like you don't *want* to support Windows. "Cross-platform" seems to mean "several Linux distributions" these days...

I'm not entirely convinced that reading the arguments from the command line and printing them back on the terminal proves anything about the actual encoding of those characters.  In the end it is cmd.exe that interprets them in both cases.  "Garbage in—garbage out", as they say.

I also don't think that pg_dump or any other CLI program has to do anything special in order to "read it correctly".  It reads what the system (Windows, cmd.exe) gives it.  If the system chooses to play tricks, there's little we can do about it.

I do not have access to a Windows system these days, but I guess the most reasonable thing at this point is to come up with a minimal and self-contained reproducer, so that someone who does can try it and see what you see on your end.  So far you have only provided some terminal invocations accompanied by error messages and vague descriptions of comparing the actual and expected output of pg_dump.

Regards,
--
Alex

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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds