[no-release-notes] bump and fix

[jycor]

The two regressions here are not easily fixable.

The problem lies in numeric types and conversions.
When we have a float64 on the left side and a numeric (decimal type underlying), converting causes a panic.

Later on, we compare the values using a float64 comparator; it seems like the comparator wants to use left type as the comparing type, and panics if the arguments are not strictly that type.

[github-actions]

	Main	PR
covering_index_scan_postgres	355.66/s	333.93/s	-6.2%
index_join_postgres	155.59/s	155.10/s	-0.4%
index_join_scan_postgres	186.04/s	186.93/s	+0.4%
index_scan_postgres	12.43/s	12.54/s	+0.8%
oltp_point_select	2514.21/s	2595.14/s	+3.2%
oltp_read_only	1813.33/s	1855.69/s	+2.3%
select_random_points	115.55/s	117.19/s	+1.4%
select_random_ranges	130.32/s	131.19/s	+0.6%
table_scan_postgres	11.76/s	11.64/s	-1.1%
types_table_scan_postgres	5.45/s	5.44/s	-0.2%

[github-actions]

	Main	PR
Total	42090	42090
Successful	16455	16455
Failures	25635	25635
Partial Successes1	5546	5546

	Main	PR
Successful	39.0948%	39.0948%
Failures	60.9052%	60.9052%

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. ↩

[Hydrocharged]

LGTM!

[Hydrocharged]

Rather than saying this should be the right type in the TODO, I'd change it to say that hash.HashOf expects the right type, which doesn't quite align with how we handle type casting.