feat: cover dictionary-encoded bind parameter columns

[fornwall]

Add a test for binds a dictionary-encoded column (what pandas often produce).

Dictionary encoding is an encoding of the same logical values, not a different logical type (Arrow columnar format, Dictionary-encoded Layout), so a driver that binds plain string columns should accept the dictionary-encoded equivalent, decoding it if the database has no native counterpart:

https://arrow.apache.org/docs/format/Columnar.html#dictionary-encoded-layout

Verified against existing drivers: sqlite, postgres, mysql and flightsql (for the example server it needed a fix: apache/arrow-go#936).

Context: Missed this when implementing a new driver, so having this test would have helped.

[lidavidm]

I think this should be just a .txtcase or derive from an existing .txtcase (e.g. see the ingest tests where ingest/string is used with some Python code to test other things while allowing some flexibility to override the test data)

[fornwall]

I think this should be just a .txtcase or derive from an existing .txtcase (e.g. see the ingest tests where ingest/string is used with some Python code to test other things while allowing some flexibility to override the test data)

👍 Made the transition to .txtcase in abe8932, adding the necessary dictionary support to the test machinery. I didn't see a clean fit for deriving from an existing .txtcase, but let me know if you think otherwise.

[lidavidm]

Sorry, I should've explained more...This is what I mean:

validation/adbc_drivers_validation/tests/ingest.py

Lines 628 to 642 in 94f8332

	def test_replace_schema(
	self,
	driver: model.DriverQuirks,
	conn: adbc_driver_manager.dbapi.Connection,
	query: Query,
	) -> None:
	subquery = query.query
	assert isinstance(subquery, model.IngestQuery)
	data = subquery.input()
	expected = subquery.expected()
	# Create a table in the default schema
	default_data = data
	# Create different data for the secondary schema
	data = data.slice(0, 2)
	data2 = data.slice(0, 1)

It's "parametrized" but the parameterization only ever uses a single test case. The test itself then transforms the data before doing something with it. That way it effectively inherits whatever customization was done for that test case without requiring a separate test case.

[fornwall]

Thanks! I transitioned to parameterization in 2ac53ff - does that match what you meant?

I found that support for dictionary encoded types other than strings is lacking in at least the sqlite/postgres driver (looking into a PR for that), so for now I'm just checking string & large_string.