Exposing SQLGetInfo

[grovesNL]

I'd like to expose some different information from SQLGetInfo like SQL_INFO_SCHEMA_VIEWS and would be happy to open PRs for this. I was wondering if we have any preference about how to expose an API like this, some ideas:

1. Expose granular functions like fn supports_info_schema_views_schemata() -> Result<bool, Error>. This might end up having quite a few functions in total (basically a function per info type).
2. Match 1:1 with SQLGetInfo and have fn info(info_type: InfoType, result: &mut InfoResult) -> Result<(), Error>. So we'd have one function and a couple enums.
3. Some combination of 1 and 2 that uses different functions for different return types depending on the type of info requested, so fn info_bitfield, fn info_bool, etc.

I like 1 because it feels idiomatic, but would be great to know if we would prefer 2/3/something else.

[pacman82]

Hello @grovesNL ,

tl;dr I agree, most of the time I'd opt for (1).

I don't like stories like "Exposing SQLGetInfo. It focuses on implementation detail. I would prefer phrasing it in terms of the use case(s). So I'd rather have an issue like "I want to get the name of a column" than "Expose SQLColAttributeW".

SQLColAttributeW also serves as an indication how such things have been solved in odbc-api in the past. You'll find private methods wrapping SQLColAttributeW like numeric_col_attribute (

odbc-api/odbc-api/src/handles/statement.rs

Line 775 in 889466a

unsafe fn numeric_col_attribute(

). These are only there to avoid repetitive code in the implementations of the functions actually exposed to the user (e.g. col_display_size).

My intuition right now is that SQLGetInfo is pretty similiar in that regard.

As you can consider me a fan of your work, I would welcome a PR. Currently my free time is pretty sparse due to a new job and some private obligations, but I can cram in a review once in a while.

Cheers,
Markus

[grovesNL]

Makes sense to me! I'll take a look at SQLColAttributeW .

Agreed about defining the use cases first. The first cases I hit in the past couple days use different parts of SQLGetInfo: knowing whether we can query information about the schema (SQL_INFO_SCHEMA_VIEWS ) and knowing whether cast functions are available (SQL_CONVERT_FUNCTIONS).

Please don't feel rushed with any of my questions/PRs by the way :) I'm using odbc-api in a new project that I'm building, but I use my fork if I hit anything that I need quickly. So far it has been working really well, so thanks for the great crate!