[C-API + CLI] Add support for named parameters in prepared statements

[Tishj]

This PR extends the functionality introduced in #5582 and implements the request made in #7076

Implementation changes / API extension

Old way

Previously the named parameter support was implemented by preparing the query, using the PreparedStatements named_parameter map to manually transform the provided data into a vector<Value> that maps the values to the right index.

We then cleared the map, and when it got bound we verify that the map is empty, otherwise we throw an exception saying that named parameters are not supported in this client.

This was only supported in the Python client.

Problems

This put the responsibility on the client to verify all the error conditions, such as the statement expects named values but they weren't provided, some are missing, too many values are provided, etc..
That also means that when this isn't checked, we could end up accepting a regular value even when we expected a named value, which shouldn't happen.

Solution

Now we have a new PendingQuery overload that takes a case_insensitive_map_t<Value> parameter, this enables us to use named parameters.
The verification of the named parameters is moved to core, and is no longer the responsibility of the client.
This change propagates throughout the entire system, meaning we don't store parameters internally as a vector anymore, but as a case_insensitive_map_t (unordered_map<string, ...>)

CLI

While working on this change, I also took the opportunity to add named parameters to the CLI:

This means this works now:

prepare q123 as select $param, $other_name, $param;
execute q123(param := 5, other_name := 3);

Result:

5	3	5

C-API

Similar to SQLite, we now have duckdb_bind_parameter_index, which retrieves the internal mapping from name -> parameter index, this also registers the value as being named, for verification purposes.

/*!
Retrieve the index of the parameter for the prepared statement, identified by name
*/
DUCKDB_API duckdb_state duckdb_bind_parameter_index(duckdb_prepared_statement prepared_statement, idx_t *param_idx_out,
                                                    const char *name);

See test/api/capi/test_capi_prepared.cpp for an example of how this is used

"Test prepared statements with named parameters in C API"

Footnote:

Mixing named and unnamed prepared parameters are still not supported, but the possibility of this has been taken into account while making these changes, so it should still be relatively low hanging fruit to add support for this.

[Tishj]

Hmm we do lose some existing functionality, now that we occupy the ComparisonEqual expression for named parameters, so I've had to edit an existing test.

Mark mentioned using param := 5 but that's currently a syntax error, maybe I should add support to the parser for that so we don't have to lose existing functionality.

EDIT: fixed

[Mytherin]

Thanks for the PR! I left some comments below. I wonder if it makes sense to unify the positional and named parameters. Positional parameters could be names that are just numbers internally, e.g. SELECT $1, $2 would translate to the names "1", "2". That might allow for code to be cleaned up to avoid having to think about these as separate things in many layers.

[Tishj]

This is still broken currently, dealing with one last hurdle unifying the named and positional parameters.
Since we need to keep the $<number> -> param_idx as a direct mapping for C-API reasons, this complicates the $<name> situation.

We can't assign the named parameters an index until we've seen all positional parameters

I can't come up with a neat solution for this problem,
maybe I could save references to the created parameter expressions, and update their indices after the fact, but that sounds dirty.

I also thought about just adding the name, and only bind them later, but we use the "unbound" parameter index in the C-API.

Maybe we have to keep the limitation that you can't mix positional/named parameters for now

EDIT:
We still don't support mixing named and positional parameters for now

[Tishj]

This comment should be updated

[Tishj]

These should be const references I feel

[Tishj]

Same for these

[Mytherin]

Thanks! LGTM