Infer prepared statement parameter types

[avantgardnerio]

Which issue does this PR close?

Closes #4683.

Rationale for this change

Described in issue.

What changes are included in this PR?

1. Code in sql_to_rel to infer parameter type
2. A test for a particular type of statement with parameters
3. A method to get the inferred types

Are these changes tested?

[x]

Are there any user-facing changes?

FlightSQL implementers can respond with types.

Additional Info

I'm opening this as a draft PR to discuss general approach. If folks are on board with it, I'll add support for a bunch more statement types and more tests.

[avantgardnerio]

@alamb @andygrove @NGA-TRAN Please review!

[alamb]

Thanks @avantgardnerio -- this is looking very nice. I left some suggestions -- hopefully they make sense!

[avantgardnerio]

this is looking very nice

Sounds like you're okay with the general approach then. I'll implement a bunch of other inference types and undraft the PR 👍

[avantgardnerio]

Filter & join were all I could find for our test dataset of SQL queries, and those both work now. I'm undrafting this and marking it ready for review.

I'll do a follow-on one for insert, update, and delete 😨

[alamb]

I plan to review this tomorrow.

[alamb]

Thank you @avantgardnerio -- I think this is looking close to mergeable as is. I left a few suggestions.

One way to proceed might be:

1. Do any cleanup on this PR you might want to do
2. Merge this PR, and file follow on tickets / PRs for:
3. a) Extract the "walk all exprs in a plan" code to its own function
4. b) Cover the remaining LogicalPlan types in "walk all exprs in a plan"

[alamb]

I think it looks good enough to go in to me @avantgardnerio

Thank you -- I do think it is worth filing tickets about the feature gaps so that other people can help / realize what is missing

Specifically, that this doens't walk all logical plan nodes yet and that it doesn't handle inference for use of parameters in anything other than binary expressions

[avantgardnerio]

walk all logical plan nodes yet

I'll file a ticket for that.

other than binary expressions

What could it infer from except those?

[alamb]

What could it infer from except those?

I was thinking stuff like $1 LIKE 'foo' for example

[avantgardnerio]

a) Extract the "walk all exprs in a plan" code to its own function
b) Cover the remaining LogicalPlan types in "walk all exprs in a plan"

I think these are done now.

[alamb]

FWIW I plan to go over this once more hopefully later today or tomorrow and if it hasn't been merged yet do so. I think it is good enough to go in as is and we can iterate on it in subsequent PRs

[ursabot]

Benchmark runs are scheduled for baseline = 64fa312 and contender = e6a0500. e6a0500 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java