Added the 'GetExpectedParameterTypes' method to the PreparedStatement…

[AlexR2D2]

This method allows to get the expected types of parameters of SQL query.

To be short.
DuckDB amalgamation can be used in the Erlang NIF. In the Erlang the parameters of SQL query are passed as terms. Term - a piece of data of any data type. We can use special Erlang NIF functions like enif_is_number(term), enif_is_binary(term) to detect the type of the term we passed into query and convert this term parameter to the duckdb::Value parameter of this detected type.

Basically, it works, but may be it would be more correct if we could get the expected types of parsed SQL query parameters from the duckdb::PreparedStatement not from the terms itself, and try convert Erlang terms to the duckdb::Value's of expected types.

[Tishj]

Can we add a D_ASSERT(it.first >= 1);?
To cover the assumption made when doing it.first - 1

And just to be safe, also D_ASSERT((it.first - 1) < expected_types.size());

[AlexR2D2]

Sure, updated. If you want, you can make any changes, I don't mind at all). I just wish the method would continue to return expected types for query parameters.

[hannes]

We might want to think about how this could be extended to named parameters.

[AlexR2D2]

We might want to think about how this could be extended to named parameters.

Maybe then replace this:
vector<LogicalType> PreparedStatement::GetExpectedParameterTypes()
to this?
unordered_map<string, LogicalType> PreparedStatement::GetExpectedParameterTypes()

For example, for SQL parameters like this $1, $2, $name, $city it will returns unordered_map like this {"1" -> LogicalType, "2" -> LogicalType, "name" -> LogicalType, "city" -> LogicalType}

So, until you made named parameters it will return a map where indexes of parameters are in the form of a string {"1" -> LogicalType, "2" -> LogicalType,... etc}

[Mytherin]

I would say the named parameters should be separate from the positional parameters - this looks fine to me for the positional parameters.