On 09/24/2016 03:52 PM, Wietse Venema wrote:
> Wietse Venema:
>> Looks good (I'll fix typos). It works with the system by using what
oops, thanks for picking that up.
> Before I forget, did you verify that:
>
> - The 'old' code reproduces the problem (postmap -q fails to look
> up a database key that contains UTF8) and the 'new' code fixes it.
The fix is not specifically about utf8 lookups, but for the issue
that Postfix was not reading the default mysql options file.
This is as per mysql documentation. I can confirm that from
my own tests on unpatched Postfix the default mysql options file
was not being read.
That corresponds to the behaviour seen by the OP.
To test this behaviour I didn't use the character set option
in the my.cnf file, but a different option that was easier for
me to test with (init-command) that executes some sql at
connection time.
> - The client will read settings in the [client] group even if
> options_group specifies a different name.
This is documented mysql behaviour. Both the client
and the specified group are read. I have verified that too
on my patch submission. I am testing against mariadb
5.5.50-1.el7_2 (the default on Centos 7.2).
I have also looked at the latest mysql
5.7.15 source and it does the same thing.
see mysql_read_default_options in mysql-5.7.15/sql-common/client.c
groups[0]= (char*) "client"; groups[1]= (char*) group; groups[2]=0;
> Otherwise I'll have to set up a mysql database to verify that myself.
>
> Wietse
Just one more thought: the patch will mean the the default mysql
options files will start to be used on installations which may contain
settings in the [client] group made for reasons other than Postfix.
Although this is expected behaviour, i.e. the [client] section is
common among all clients, some installations may have relied
on this not happening. It is worth a warning in the release notes
to check mysql default option files [client] section for any options
that are not wanted for Postfix.
John
