You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Some SQL statements require a schema or even a catalog to be specified for successful execution. For example, SELECT * FROM my_table might fail on certain databases since the context is not fully specified, i.e. on which catalog.schema.table the statement is executing.
To provide such context, we use set_header on the client side to encode it into the request metadata. For instance, our implementation calls flight_sql_client.set_header("database", schema_name) to specify the schema. However, the schema key database is determined by the server, and the client has no way to retrieve this key dynamically. Worse, if the key changes on the server side, client code may break.
I propose adding an interface to FlightSqlService that allows the client to retrieve the schema or catalog key for encoding context in request metadata. This would enhance flexibility for client-server interaction.
Describe the solution you'd like
Add a interface to FlightSqlService, such as do_get_schema_key, that allows a client to get the schema key from the server.
Describe alternatives you've considered
Adding a protocol-determined constant SCHEMA_KEY may also work but not very flexible.
Additional context
The text was updated successfully, but these errors were encountered:
If this is part of the flightsql specification it makes sense. If this is an extension (not part of Arrow FlightSQL) then I think it would be better kept in users of the crate (rather than adding a new API)
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Some SQL statements require a schema or even a catalog to be specified for successful execution. For example,
SELECT * FROM my_table
might fail on certain databases since the context is not fully specified, i.e. on which catalog.schema.table the statement is executing.To provide such context, we use
set_header
on the client side to encode it into the request metadata. For instance, our implementation callsflight_sql_client.set_header("database", schema_name)
to specify the schema. However, the schema keydatabase
is determined by the server, and the client has no way to retrieve this key dynamically. Worse, if the key changes on the server side, client code may break.I propose adding an interface to
FlightSqlService
that allows the client to retrieve the schema or catalog key for encoding context in request metadata. This would enhance flexibility for client-server interaction.Describe the solution you'd like
Add a interface to
FlightSqlService
, such asdo_get_schema_key
, that allows a client to get the schema key from the server.Describe alternatives you've considered
Adding a protocol-determined constant
SCHEMA_KEY
may also work but not very flexible.Additional context
The text was updated successfully, but these errors were encountered: