Fix a segmentation fault which Mysql2::Statement#fields causes.

[kanata2]

I found a bug(segmentation fault) about Mysql2::Statement#fields.

environment

• ruby 2.4.1
• mysql 5.7.16
• mysql2 0.4.6
• MacOS 10.12.5

example

This is probably minimal example.

stmt = client.prepare("SELECT * FROM hoge where id = '?'")
puts stmt.fields # => work!

stmt = client.prepare("INSERT INTO hoge(blah) VALUES (?)")
puts stmt.fields # => segmentation fault

I think that it doesn't be passed the expected value for mysql_fetch_fields because mysql_stmt_result_metadata returns NULL for INSERT, UPDATE, DELETE etc.
(ref: https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-result-metadata.html)

And therefore, in case metadata is NULL, I change fields function to return an empty array.
Please review this 🙏

[sodabrew]

Good find! I wonder if the right answer is nil instead of []. The consistent data type feels reasonable to me, I just want to make sure it's not losing some important distinction between "no fields" and "not applicable to this query type".

[sodabrew]

It doesn't need a new table, you can insert into the same mysql2_test table.

[kanata2]

thanks! I fixed it.

[kanata2]

Thank you for your review!

I just want to make sure it's not losing some important distinction between "no fields" and "not applicable to this query type".

I think so too.
I think that in case of "no fields", it should return [], but in case of "not applicable query type", it should probably raise an exception.
However, I did not know how to distinguish whether given queries are applicable or not...
What do you think?

[sodabrew]

I spent some time with this, and decided that nil should be the return type – "no fields" is not valid in SQL as far as I can tell, because you can't write a SELECT without fields, nor can you create a table without columns.

There were a few other issues to address, so I've committed a similar but broader change and credited you with the initial fix. Thank you!