Support using same parameter multiple times

[NathanGabrielson]

Right now we always don't allow a query to use the same parameter in multiple locations.

Technically that should always be allowed and then we'll fail later down the line if you're trying to bind a parameter and compare it to something with an incompatible type.

But the error messages we have if I just completely remove the check are a little ugly, so I added some code to our function that handles the types of parameters by breaking if you try to use a parameter as multiple incompatible types within the same query.

So for instance the query: select * from table where column_int = $1 and column_float4 = $1 should be fine because integer/int4 is compatible with float4.
But the query: select * from table where column_text = $1 and column_int = $1 will error because text and integer/int4 are not compatible.

[github-actions]

	Main	PR
covering_index_scan_postgres	1103.33/s	1121.17/s	+1.6%
index_join_postgres	159.01/s	161.20/s	+1.3%
index_join_scan_postgres	195.00/s	198.71/s	+1.9%
index_scan_postgres	11.99/s	11.99/s	0.0%
oltp_point_select	2433.63/s	2457.22/s	+0.9%
oltp_read_only	1810.17/s	1853.47/s	+2.3%
select_random_points	125.84/s	127.07/s	+0.9%
select_random_ranges	831.61/s	829.84/s	-0.3%
table_scan_postgres	11.84/s	11.66/s	-1.6%
types_table_scan_postgres	5.40/s	5.36/s	-0.8%

[github-actions]

	Main	PR
Total	42090	42090
Successful	17911	17911
Failures	24179	24179
Partial Successes1	5634	5634

	Main	PR
Successful	42.5541%	42.5541%
Failures	57.4459%	57.4459%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[fulghum]

Looks good!