feat(c/driver_manager): add connection profile interface

[zeroshade]

An attempt to implement the ideas as suggested in #3765 to provide the ability to specify and load connection profiles to define options for use by the driver manager.

This creates an AdbcConnectionProfile struct and defines an AdbcConnectionProfileProvider function pointer typedef to allow for customized management of profiles. This also implements a default file-based profile provider as described in #3765 (comment) which will be used if no custom provider has been set.

This allows easy expansion in the future for non-file-based connection profile providers while still implementing the easier case of using file-based profiles, including hierarchical specification for now. See the documentation comments added to adbc_driver_manager.h for the full description of the semantics and explanation.

[zeroshade]

CC @davidhcoe

if there's anyone I missed please feel free to tag others that might be interested in looking this over and reviewing it. Once everyone is onboard with the design and ideas I'll implement the handling of these profiles for the other language bindings.

[paleolimbot]

Cool!

All just questions from me to take or leave 🙂

[paleolimbot]

Do you want to wrap this in a top level [profile] item (like pyproject.toml's [project] or Cargo.toml's [workspace])?

Suggested change

	/// version = 1
	/// driver = "driver_name"
	///
	/// [options]
	/// option1 = "value1"
	/// option2 = 42
	/// option3 = 3.14
	/// [adbc.profile]
	/// version = 1
	/// driver = "driver_name"
	///
	/// [options]
	/// option1 = "value1"
	/// option2 = 42
	/// option3 = 3.14

[zeroshade]

Personally I was trying to avoid having to do that. Is there any benefit to doing so?

[paleolimbot]

Just seemed like a common idiom in .toml configs, perhaps to allow for future expansion (e.g., if you ever want >1 profile to live in one .toml)

[zeroshade]

i think after a lot of discussion between myself, @lidavidm and @ianmcook we came to the decision that we don't want more than 1 profile to live in one .toml file haha 😄

[ianmcook]

Having multiple connection profiles defined in a single TOML file could potentially be nice, but it complicates the profile search procedure, and I worry that it could confuse users.

[paleolimbot]

Suggested change

	AdbcStatusCode (*GetDriverName)(struct AdbcConnectionProfile* profile,
	const char** driver_name, struct AdbcError* error);
	AdbcStatusCode (*GetDriverName)(struct AdbcConnectionProfile* profile,
	const char** driver_name, AdbcDriverInitFunc* init_func, struct AdbcError* error);

Is there any value to allowing a profile to optionally specify the init function directly? (R could maybe use this to find R package versions of drivers)

[zeroshade]

The way the code is set up doesn't allow for this. If there is an init func set then the profile handling is currently entirely skipped and it's up to the init_func to handle everything. Given the way we envision profiles working, I don't think that it makes sense for the profile to set or specify the init function.

[paleolimbot]

I think you'd just set args->init_func instead of args->driver (understood if you'd prefer not to)

[zeroshade]

I personally prefer not, but I'm open to it if others think it's worthwhile.

[davidhcoe]

@CurtHagenlocher will be interested in this as well.

[lidavidm]

nit, but I think we should explain this as its own thing, and cite ODBC as an inspiration further down

[lidavidm]

Hmm. Why not use option = { env_var = "NAME" }?

[ianmcook]

That would prevent us from using environment variables to define substrings, which we will need for the drivers that expect their connection arguments to be in a URI.

uri = "scheme://host:port?user=user&pw=env_var(PASSWORD)

[ianmcook]

Should we consider using ${} instead of env_var()?

That is more concise and makes escaping literals easier (e.g. with \$ or $$).

[lidavidm]

(Does the manager call release or does the application?)

[zeroshade]

@CurtHagenlocher @davidhcoe @lidavidm @ianmcook any further comments?