Thread: [HACKERS] Adding -E switch to pg_dumpall
Hi all, While looking at a user problem, I got surprised that pg_dumpall does not have a -E switch. This has been discussed a bit in the past like here: https://www.postgresql.org/message-id/75E4C42D37E6A74E9FB57C2E9F1300D60107073E@tiger.nexperience.com Now it is possible to enforce the encoding used by using PGCLIENTENCODING but I think that a switch would be useful as well, particularly for Windows where "set" needs to be used. Are there any objections to a patch adding support for that? Such a patch should do: - Call PQsetClientEncoding if an encoding is defined after getting a connection. - Pass down -E to pg_dump calls if something is set. Thoughts? -- Michael
On Fri, Jul 14, 2017 at 12:39 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > While looking at a user problem, I got surprised that pg_dumpall does > not have a -E switch. This has been discussed a bit in the past like > here: > https://www.postgresql.org/message-id/75E4C42D37E6A74E9FB57C2E9F1300D60107073E@tiger.nexperience.com > > Now it is possible to enforce the encoding used by using > PGCLIENTENCODING but I think that a switch would be useful as well, > particularly for Windows where "set" needs to be used. Are there any > objections to a patch adding support for that? Such a patch should do: > - Call PQsetClientEncoding if an encoding is defined after getting a connection. > - Pass down -E to pg_dump calls if something is set. > > Thoughts? Attached is a patch to add support for this switch. I am parking that in the next CF. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Hello Michaël-san, > Attached is a patch to add support for this switch. I am parking that > in the next CF. I'm in favor of this feature for consistency with pg_dump, and as the environment variable workaround is not specially elegant and can induce issues of its own. Patch applies and compiles. No special regression tests are provided, but this seems ok to me as it just forward the option to pg_dump, which I have no doubt is heavily tested. Or not. Anyway it is consistent... Manually tested with UTF8, latin1 (including conversion errors), non existing. Code is straightforward. Doc and help are both fine. Ok for me. I switched the status to "Ready for committers". -- Fabien.
On Thu, Jul 20, 2017 at 11:17 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > Ok for me. I switched the status to "Ready for committers". Thanks for the review, Fabien. -- Michael
On Fri, Jul 21, 2017 at 9:21 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Thu, Jul 20, 2017 at 11:17 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: >> Ok for me. I switched the status to "Ready for committers". > > Thanks for the review, Fabien. LGTM. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Sat, Sep 2, 2017 at 1:32 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Jul 21, 2017 at 9:21 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> On Thu, Jul 20, 2017 at 11:17 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: >>> Ok for me. I switched the status to "Ready for committers". >> >> Thanks for the review, Fabien. > > LGTM. Committed. Thanks for the commit. -- Michael