Couple fixes

[bbeaudreault]

@sougou as discussed, this removes the column count doesn't match value count error when operating on a table with an auto increment. I had to avoid an "index out of range" panic by modifying extractColumnValues. Let me know what you think.

I also included a fix for @giaquinti in the parser for SET CHARACTER SET 'utf8'. I can move to another PR if you'd like but the change was trivial enough that it seemed worth avoiding the overhead.

[bbeaudreault]

I added a small commit to ignore lc_messages per #3111

[sougou]

Are you sure this is needed? I think this code is unreachable because if no value was specified, the colnum would have been computed as -1, and there is a higher level check that skips calling this function.

[bbeaudreault]

I added this to fix a index out of range panic that occurred in my test without it. Do you think a better fix is in order?

[sougou]

Do you have the call stack? I still can't see how it happened.

[bbeaudreault]

@sougou ok I implemented an approach as we discussed. Let me know what you think.

While I was in there I converted all the errors in dml.go to vterrors.

[bbeaudreault]

@sougou FYI I'm going to be away for the next week, but if you have any comments I might be able to address them tomorrow morning.

[sougou]

Sinc you're going to be away, if there is an issue with bitval, I'll need to add a fix for it before this is submitted. Let me know if it's ok.

[sougou]

I actually think that the Bit to BitVal conversion may be incorrect. So, I'll need to look at how a Bit Value gets built and how it gets converted back. But I don't have time right now. I'll verify this later.

[sougou]

Based on this:

mysql> create table a(id int, val bit(8) default b'101', primary key(id));
Query OK, 0 rows affected (0.02 sec)

mysql>
mysql> describe a;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | NO   | PRI | 0       |       |
| val   | bit(8)  | YES  |     | b'101'  |       |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)

We have two problems:

1. The sqltypes.Value we build for bit fields is incorrect here: https://github.com/youtube/vitess/blob/1595283c1e48b4c80ead69245292722e0ad4efc0/go/vt/vttablet/tabletserver/schema/schema.go#L159.
2. The SQLVal we build here should just be a string representation, likely escaped because the data will be binary. Basically, the value should be treated like a regular quoted string.

There is also a more concise and efficient way to do this without the elaborate switch.

I'll patch this PR and add a new commit to make the above fixes.

[sougou]

I ran an audit for default values for all data types. Only the bit type has a representation that is different from what mysql would otherwise return as a value. The more exotic geometry and json types don't allow default values. So, I'm thinking of just special-casing this.

Also, we don't have code to convert something like b'101' to the binary representation. So, I'm thinking of making mysql do this for us with select b'101'.

[sougou]

I didn't want to lose history on the conversation. So, instead of creating a brand new consolidated PR of yours and mine, I've created a PR to add to your branch: HubSpot#7.

The other option is to submit your changes to YouTube, and then immediately submit my PR.

PS: Merging my PR into yours will cause CLA bot to complain, but we can ignore it.

[bbeaudreault]

Very clever :) pulled in your fix, let's see how travis looks.

[sougou]

LGTM