Fix Infer prepare statement type tests

[brayanjuls]

Which issue does this PR close?

• Closes Fix PREPARE statement tests #15577

Rationale for this change

This intent to correct issues on the prepare statements infer type tests. Currently they are not correctly asserting the expected behavior specially when we try to validate types.

What changes are included in this PR?

• Restore the original naming.
• Include the "PREPARE" statement clause without type.
• Update insta snapshots.
• Pending: Get the inferred types part of the plan.

Are these changes tested?

Yes

Are there any user-facing changes?

No

[brayanjuls]

Currently when the logical plan is created it does not include the type inferred, this result in some issues when we try to call the function plan.with_param_values(param_values) as it tries to extract the type from the plan but it is empty. Are we expecting the plan to contain the type at this time? if so probably there is another bug we need to investigate.

[brayanjuls]

@alamb @qstommyshu any advice on where to look to debug why the plan is not properly generating the inferred type?

[qstommyshu]

Hi @brayanjuls ,

the reason why this happen is there is no parameters being passed to the sql, but the sql itself contains positional arguments like $1 and $2, please refer to https://datafusion.apache.org/user-guide/sql/prepared_statements.html#inferred-types.

The simple way you can fix it is by adding the position arguments type to the sql like how it was done in test_prepare_statement_to_plan_one_param. If you want to dig into the details about it, you can check how planner parse PREPARE statement and transfer it into a logical plan.

[brayanjuls]

but wouldn't that mean the type is not being inferred, but instead we are explicitly declaring it?

Thanks, I would check the planner parser.

[qstommyshu]

I didn't check the details for parsing "PREPARE" statement yet, but I think the type inference behaviour depends on how the planner parser is implemented, it could be either way.