[prev in list] [next in list] [prev in thread] [next in thread]
List: pgsql-bugs
Subject: Re: pg_dump's "--exclude-table" and "--exclude-table-data" options are ignored and/or cause the dump
From: Juan_José_Santamaría_Flecha <juanjo.santamaria () gmail ! com>
Date: 2020-07-22 16:58:00
Message-ID: CAC+AXB18qKozX6BjPm89=XEh4YJeULO+ATvwpeNt5i0G_+iy=g () mail ! gmail ! com
[Download RAW message or body]
On Wed, Jul 22, 2020 at 5:17 PM <tutiluren@tutanota.com> wrote:
> Jul 22, 2020, 9:36 AM by juanjo.santamaria@gmail.com:
>
> I can reproduce a test case in an English_United States.1252 WIndows 10
> machine, and the setting "Beta: Use unicode UTF-8 for worldwide language
> support", as mentioned above, worked in that case.
>
>
> I've tried to explain this both in my initial question and as a response
> to those few who replies: the error output is not what always happens. I
> just included it for the cases where it does error out. When it does run
> the command, it *ignores the exclude rules*. That is, it dumps the data
> anyway. I thought I was crystal-clear when describing my problem, but no
> matter how careful I am, people always quote some specific part and focus
> on that, ignoring my overall explanation.
>
> To be clear: The problem is not solved. I'm not one step closer to a
> solution. It's ignoring the rule or displaying the nonsensical errors, but
> never actually works.
>
I am afraid I must insist, pg_dump is expecting a shell that honors
"client_encoding = 'UTF8'", and all the issues you are describing fit the
mold of a CMD that is not doing so: fails when using extended characters
with "invalid byte sequence for encoding "UTF8"" or gives wrong results,
and works when you use plain ASCII.
Please read an excerpt from [1]:
"The current changes also don't cover what is required for our "processed
input mode" that presents an editable input line for applications like
CMD.exe. We are planning and actively updating the code for popup windows,
command aliases, command history, and the editable input line itself to
support full true Unicode as well."
Not sure I can help any further if your system is below Windows 10 April
2018 Update (Version 1803) and cannot active true (but beta) UTF8 support.
Maybe using a client from a POSIX machine as an alternative.
[1]
https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/
Regards,
Juan José Santamaría Flecha
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, Jul 22, 2020 at 5:17 PM <<a \
href="mailto:tutiluren@tutanota.com" target="_blank">tutiluren@tutanota.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Jul 22, 2020, 9:36 AM by <a href="mailto:juanjo.santamaria@gmail.com" \
target="_blank">juanjo.santamaria@gmail.com</a>:<br></div><blockquote \
style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div \
dir="ltr"><div>I can reproduce a test case in an English_United States.1252 WIndows \
10 machine, and the setting "Beta: Use unicode UTF-8 for worldwide language \
support", as mentioned above, worked in that \
case.<br></div></div></blockquote><div><br></div><div>I've tried to explain this \
both in my initial question and as a response to those few who replies: the error \
output is not what always happens. I just included it for the cases where it does \
error out. When it does run the command, it *ignores the exclude rules*. That is, it \
dumps the data anyway. I thought I was crystal-clear when describing my problem, but \
no matter how careful I am, people always quote some specific part and focus on that, \
ignoring my overall explanation.<br></div><div><br></div><div>To be clear: The \
problem is not solved. I'm not one step closer to a solution. It's ignoring \
the rule or displaying the nonsensical errors, but never actually \
works.<br></div></div></blockquote><div><br></div><div>I am afraid I must insist, \
pg_dump is expecting a shell that honors "client_encoding = \
'UTF8'", and all the issues you are describing fit the mold of a CMD \
that is not doing so: fails when using extended characters with "invalid byte \
sequence for encoding "UTF8"" or gives wrong results, and works when \
you use plain ASCII.</div><div><br></div><div>Please read an excerpt from \
[1]:</div><div><br></div><div>"The current changes also don't cover what is \
required for our "processed input mode" that presents an editable input line for \
applications like CMD.exe. We are planning and actively updating the code for popup \
windows, command aliases, command history, and the editable input line itself to \
support full true Unicode as well."<br></div><div><br></div><div>Not sure I can \
help any further if your system is below Windows 10 April 2018 Update (Version 1803) \
and cannot active true (but beta) UTF8 support. Maybe using a client from a POSIX \
machine as an alternative.</div><div><br></div><div>[1] <a \
href="https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf- \
8-output-text-buffer/">https://devblogs.microsoft.com/commandline/windows-command-line \
-unicode-and-utf-8-output-text-buffer/</a></div><div><br></div><div>Regards,</div><div><br></div><div>Juan \
José Santamaría Flecha</div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic