Add methods in the Result object to get metadata about the fields available in the result

[stof]

Feature Request

Q	A
New Feature	yes
RFC	no

Summary

Easy things to implement:

• Result::getColumnCount(): int
• Result::getColumnName(int $index): string

Trickier to abstract: Result::getColumnType(int $index) as we would have to define an abstraction for the column type. So not sure this should be part of this API for now.

Looking quickly, here is what I found for the drivers we have in core

• ext-sqlite3 has SQLite3Result::numColumns, SQLite3Result::columnName and SQLite3Result::columnType (returning an integer corresponding to some constants)
• PDO has PDOStatement::columnCount and PDOStatement::getColumnMeta (returning a shape with many keys and potentially not implemented by custom PDO drivers, but implemented by all core PDO drivers)
• ext-pgsql has pg_num_fields, pg_field_name and pg_field_type
• ext-mysqli has mysqli_result::$field_count to the field count and mysqli_result::fetch_field_direct to get info about the field
• ext-ibm-db2 has db2_num_fields, db2_field_name and db2_field_type (and a few other db2_field_* functions)
• ext-oci8 has oci_num_fields, oci_field_name and oci_field_type
• ext-sqlsrv has sqlsrv_num_fields and sqlsrv_field_metadata (which gives the metadata for all fields as a list instead of taking an index as argument like for other extensions)

[stof]

Actually, columnCount is already part of the Result API.

[stof]

Regarding getColumnName, I suggest we throw an exception if the (0-based) index does not exist in the Result object. It will be easier for static analysis than making it return string|null as the expected usage is to pass valid indexes.

[derrabus]

The column name part looks interesting. Do you want to give it a try?