No access to field types for a query result

[dbussink]

In mysql2, a result has a field_types method to get access to the field types of the result. Trilogy doesn't seem to provide any way to get access to these in the Ruby layer. The C driver does provide it, but it's not exposed in Ruby.

The Ruby driver does use it for casting purposes, so it's internally available. See also:

trilogy/contrib/ruby/ext/trilogy-ruby/cext.c

Lines 738 to 742 in 640f990

	column_info[i].type = column.type;
	column_info[i].flags = column.flags;
	column_info[i].len = column.len;
	column_info[i].charset = column.charset;
	column_info[i].decimals = column.decimals;

There the data is read into column_info but that data is ephemeral for the result object and not included in the final result.

We were looking to move to Trilogy, but we do need access to this field type information in some way or another. From purely that perspective, it doesn't have to be compatible 1:1 with how mysql2 works, as long as it's available in some way.

I'm happy to contribute a PR to add this, but I don't really know what the preferred way of adding this would be. Should it be for example to column_info and then lazily create entries in a field_types method? Or should we build field_types directly like fields is built (although often it won't really be needed, as is clear since it's not present yet and already extensively used with Rails).

Or should there be a totally different function than field_types that returns the types not as strings like mysql2 does, but with integer constants + any of the additional flags / size attributes etc. for the type? If there's any preference with how to make this available, I'm also able to start a PR for that then.

[brianmario]

I'd be in favor of an API that exposes all of the column info available from the C API.

Maybe something like Result#columns which returned an array of Result::Column classes that had those attributes like name, type, flags, etc. And yeah, having this method create the array of Result::Column's lazily would be ideal. This would sorta duplicate what's already available via the fields attribute, but maybe that could be removed in a future release, in favor of this new columns method, to avoid making a breaking change all at once?