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

From: Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>
To: tutiluren(at)tutanota(dot)com
Cc: Pgsql Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.
Date: 2020-07-28 06:12:48
Message-ID: CACACo5RkD8y4B=H7y409c3jK+oAnd57o0et9r_F8pMrs8OyJiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jul 28, 2020 at 1:15 AM <tutiluren(at)tutanota(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-07-28 11:21:09 BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds
Previous Message Etsuro Fujita 2020-07-28 02:20:49 Re: BUG #16500: SQL Abend. select multi_key_columns_range_partition_table