Skip Menu |
 

This queue is for tickets about the DBD-mysql CPAN distribution.

Report information
The Basics
Id: 119079
Status: resolved
Priority: 0/
Queue: DBD-mysql

People
Owner: MICHIELB [...] cpan.org
Requestors: tzs [...] eacceleration.com
Cc: pali [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: unexpected handling of mysql_enable_utf8/mysql_enable_utf8 => 0
Date: Wed, 30 Nov 2016 12:18:24 -0800
To: bug-DBD-mysql [...] rt.cpan.org
From: Tim Smith <tzs [...] eacceleration.com>
Download (untitled) / with headers
text/plain 1.8k
At line 1884 of dbdimp.c, it handles the mysql_enable_utf8/mysql_enable_utf8mb4 flags in the options hash: if ((svp = hv_fetch(hv, "mysql_enable_utf8mb4", 20, FALSE)) && *svp && SvTRUE(*svp)) { mysql_options(sock, MYSQL_SET_CHARSET_NAME, "utf8mb4"); } else if ((svp = hv_fetch(hv, "mysql_enable_utf8", 17, FALSE)) && *svp) { /* Do not touch imp_dbh->enable_utf8 as we are called earlier * than it is set and mysql_options() must be before: * mysql_real_connect() */ mysql_options(sock, MYSQL_SET_CHARSET_NAME, (SvTRUE(*svp) ? "utf8" : "latin1")); if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) PerlIO_printf(DBIc_LOGPIO(imp_xxh), "mysql_options: MYSQL_SET_CHARSET_NAME=%s\n", (SvTRUE(*svp) ? "utf8" : "latin1")); } The logic here leads to surprising results. If when connecting you give this: mysql_enable_utf8mb4 => 1 you get MYSQL_SET_CHARSET_NAME set to utf8mb4, as you would expect, . Similarly, mysql_enable_utf8 => 1 gives MYSQL_SET_CHARSET_NAME set to utf8, just as expected, and not specifying either option results in MYSQL_SET_CHARSET_NAME not being set so you presumably get whatever the underlying mysql default is. Where it gets weird is if you give one of these: mysql_enable_utf8mb4 => 0 or mysql_enable_utf8 => 0. The former is equivalent to not specifying an option, and so you get the underlying mysql default for MYSQL_SET_CHARSET_NAME. The later, however, results in MYSQL_SET_CHARSET_NAME set to latin1. It seems quite counterintuitive that if I want latin1, the way to get it is with mysql_enable_utf8 => 0, and mysql_enable_utf8mb4 => 0 will not get that (unless that happens to be the underlying default). -- Tim Smith tzs@eacceleration.com
Download (untitled) / with headers
text/plain 474b
Hi Tim! On Wed 30 Nov 2016 15:18:37, tzs@eacceleration.com wrote: Show quoted text
> It seems quite counterintuitive that if I want latin1, the way to get > it is with mysql_enable_utf8 => 0, and mysql_enable_utf8mb4 => 0 will > not get that (unless that happens to be the underlying default).
You're right on that! Also, the behaviour of mysql_enable_utf8 => 0 is not documented. My proposal would be to explicitly document this behavior and leave it at that. Do you agree? -- Michiel
Download (untitled) / with headers
text/plain 875b
On Štv Dec 01 03:12:50 2016, MICHIELB wrote: Show quoted text
> Hi Tim! > > On Wed 30 Nov 2016 15:18:37, tzs@eacceleration.com wrote: >
> > It seems quite counterintuitive that if I want latin1, the way to get > > it is with mysql_enable_utf8 => 0, and mysql_enable_utf8mb4 => 0 will > > not get that (unless that happens to be the underlying default).
> > > You're right on that! Also, the behaviour of mysql_enable_utf8 => 0 is > not documented. > > My proposal would be to explicitly document this behavior and leave it > at that. Do you agree? > > -- > Michiel
If mysql_enable_utf8 is not specified then default encoding (probably announced by server?) is used. I think we should explicitly set latin1 as default even if mysql_enable_utf8 is not set. That would at least make DBD::mysql deterministic on different machines, where are different default values... What do you think?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.