The problem happened because "mysql" didn't send mysql_select_db() if
the current active database was specified in USE.
Now it always send mysql_select_db().
Rebuilding of completion hash is skipped in the same db is used
(for performance purposes).
Correct a bug (that I introduced, after using Oracle's database software for
too many years) where the length of the database-sent data is incorrectly
used to infer NULLness.
- Add new function 'ssl_verify_server_cert' which is used if we are
connecting to the server with SSL. It will compare the hostname in
the server's cert against the hostname that we used when connecting
to the server. Will reject the connection if hostname does not match.
- Add new option "OPT_SSL_VERIFY_SERVER_CERT" to be passed to mysql_options
which will turn on checking of servers cert.
- Add new argument "ssl-verify-server-cert" to all mysql* clients which
will activate the above option.
- Generate a new server cert with 1024 bits that has "localhost" as the server name.
Lines with column names consisting of national letters
were wrongly formatted in "mysql --table" results:
mysql> SELECT 'xxx xxx xxx' as 'xxx xxx xxx';
+-------------------+
| xxx xxx xxx |
+-------------------+
| xxx xxx xxx |
+-------------------+
1 row in set (0.00 sec)
It happened because in UTF-8 (and other multibyte charsets)
the number of display cells is not always equal to the number
of bytes of the string.
Data lines (unlike column name lines) were formatted correctly,
because data lines were displayed taking in account number of
display cells. This patch takes in account number of cells when
displaying column names, the same way like displaying data lines does.
Note: The patch is going to be applied to 4.1.
Test case will be added after merge to 5.0,
into "mysql.test", which appeared in 5.0.
mysql.cc:
Adding column name allignment using numcells(),
the same to data alignment, which was implemented earlier.
does not have "NOT NULL" attribute set. Also, calculate the padding
characters more safely, so that a negative number doesn't cause it to
print MAXINT-n spaces.
internal charset to one associated with currently being handled query.
To note such a query can come from interactive client either.
There was a discussion within replication team and Monty who's suggestion won.
It avoids straightforward parsing of all `set' queries that could affect client side
character set.
According to the idea, mysql client does not parse `set' queries but rather cares of
`charset new_cs_name' command.
This command is generated by mysqlbinlog in form of exclaiming comment (Lars' suggestion)
so that enlightened clients like `mysql' knows what to do with it.
Interactive human can switch between many multi-byte charsets during the session
providing the command explicitly.
To note that setting new internal mysql's charset does not
trigger sending any `SET' sql statement to the server.
