metadata function prepare_column_descriptions doesn't handle booleans or bigint(e.g. postgresql)

[kgday]

Hi there, Using metadata utility function prepare_column_descriptions and execute interprets boolean fields at dt_string. This makes it not possible to determine whether the field is boolean or not.

In the type conversion class template in column-info there is no boolean handling:

may I suggest inserting in the else if chain in from_base(): else if (type_name.find("boolean") != std::string::npos || type_name.find("BOOLEAN") != std::string::npos || type_name.find("bool") != std::string::npos || type_name.find("BOOL") != std::string::npos) { ci.type = dt_integer; } ?

Also may I suggest adding a field to the column_info struct for the raw data type name? This could add as a fall back for the case of further back-ends added.

Thanks, Kevin.

[kgday]

Also similarly with bigint with postgresql - is interpreted as a string instead of long long.

[kgday]

I worked around this by creating my own column-info and types with conversion routine for the project I was working on (creating code generation utility creating model structs from an existing database).

[vadz]

Could you please show the actual code using the function and demonstrating the problem? Ideal would be to have a new unit test for this in tests/common-tests.h. Of course, really ideal would be to have a PR with the test case and the fix for it, but a test case on its own would already be very useful. TIA!

[kgday]

Just used the code from the docs. Any postgresSql bigint or boolean column gives a column_info.data_type of dt_string.

In the column_info.h column_info conversion class template you can see that no handling for bigint or boolean is in place so it defaults to dt_string.

I ended up copying the column_info.h file to a new file, and modifiying with my own renamed type - 'mycolumn_info', a mydata_type enum with a boolean entry in it and using that for into(). This allowed me to do what I needed.

[kgday]

I wonder if a dt_bool entry in the data_type enum might be a good idea, a couple of databases do support it.

[kgday]

By the way SOCI is an excellent library. I am enjoying getting to know it.