Preserve numeric overflow handling in lookup joins

[zachmu]

Preserves numeric overflow handling and validates adaptive keys and multi-table lookup joins across PostgreSQL types.

Companions: dolthub/dolt#12034 and dolthub/go-mysql-server#3997.

[github-actions]

	Main	PR
Total	42090	42090
Successful	20726	20725
Failures	21364	21365
Partial Successes1	5419	5419

	Main	PR
Successful	49.2421%	49.2397%
Failures	50.7579%	50.7603%

${\color{red}Regressions (1)}$

subselect

QUERY:          select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);
RECEIVED ERROR: timeout during Receive

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

[itoqa]

Commit: 60ac11a: 14 test cases ran, 14 passed ✅.

Summary

Coverage spans database value handling and lookup behavior, including normal reads and writes, numeric rounding and overflow recovery, transaction rollback, duplicate and collapsed-key matching, date and UUID handling, composite keys, and preservation of unmatched rows. It includes both happy-path behavior and boundary or adversarial cases across joins, storage layouts, and error recovery.

Safe to merge — the run found no PR-attributable regressions, new failures, or previously flagged failures, and all exercised behaviors passed. No merge blocker is indicated; unrelated observations do not add merge risk.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	Values 999.98 and 999.99 were stored successfully. The value 1000.00 returned a numeric overflow error and was not stored.
✅	—	General	The failed insert returned a numeric overflow error, left the table empty after rollback, and the retry stored only 12.34 and 56.78.
✅	—	Lookup	Matching keys returned the expected rows across integer, floating-point, numeric, text, date, UUID, and large-text values. Keys without a converted match were correctly left out of the inner joins.
✅	—	Lookup	The left join returned the matching destination for source row 1 and kept source rows 2 and 3 with empty destination IDs. The source row count stayed at three.
✅	—	Lookup	The lookup returned destination 2 when the extra filter allowed it. When the filter matched nothing, the source row remained with an empty destination value.
✅	—	Lookup	The lookup returned all four expected rows when two large integer keys converted to the same floating-point value. Both source rows matched both destination rows, so no valid match was hidden.
✅	—	Lookup	The date matched the timestamp at midnight and correctly excluded the later time on the same day.
✅	—	Numeric	Inserting 1000.00 into a NUMERIC(5,2) column returned SQLSTATE 22003 with a numeric field overflow message, and the invalid row was not saved.
✅	—	Numeric	Casting 12.345 to NUMERIC(5,2) returned 12.35 and an in-range status.
✅	—	Rev	Inserting a value that is too large for NUMERIC(5,2) failed with SQLSTATE 22003 and a numeric field overflow message. The server did not return an internal-error code.
✅	—	Rev	A numeric overflow did not break the database connection. The next insert succeeded, and the saved value was returned correctly.
✅	—	Rev	The lookup join returned both matching rows, (1, 10) and (1, 11), in the expected order. No duplicate match was lost and no extra row appeared.
✅	—	Storage	Both source rows matched the expected destination labels in sequence order.
✅	—	Storage	Each of the three table layouts returned exactly one matching UUID row.

Tip

Reply with @itoqa to send us feedback on this test run.

[coffeegoddd]

@zachmu DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.48	2.48	0.0
groupby_scan_postgres	82.96	86.0	3.66
index_join_postgres	2.3	2.39	3.91
index_join_scan_postgres	1.64	1.67	1.83
index_scan_postgres	475.79	475.79	0.0
oltp_point_select	0.39	0.39	0.0
oltp_read_only	6.67	6.67	0.0
select_random_points	0.74	0.75	1.35
select_random_ranges	1.08	1.1	1.85
table_scan_postgres	467.3	475.79	1.82
types_table_scan_postgres	1191.92	1191.92	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	4.57	4.57	0.0
oltp_insert	2.26	2.26	0.0
oltp_read_write	12.75	12.75	0.0
oltp_update_index	2.48	2.48	0.0
oltp_update_non_index	2.22	2.22	0.0
oltp_write_only	5.88	5.88	0.0
types_delete_insert_postgres	5.0	5.0	0.0

[itoqa]

Ito Diff Report — 60ac11a → a18dfa1: 16 test cases ran, 1 new failure ❌, 15 passing ✅.

Diff Summary

The run broadly exercised database compatibility across normal operations, type boundaries, joins, formatting, extension lifecycle, and concurrency, including several edge and failure-handling scenarios. Most covered behavior appears healthy, but trigger workflows that process variable-length arguments have a functional gap and cannot be created when slice-based arguments are used.

Merge with caution — the PR introduces a medium-impact compatibility failure in trigger argument handling, preventing affected trigger workflows from being created while simpler trigger paths remain functional. This is attributable to the change and warrants resolution before relying on full trigger compatibility; no unrelated findings are driving the verdict.

Tests run by Ito

Result	State	Severity	Type	Description
❌	❌ New Failure		General	The trigger function could not be created when its body used a TG_ARGV slice, so the test could not verify the expected argument values for all four trigger operations. The recorded run reached only partial INSERT logging; UPDATE, DELETE, and TRUNCATE results were unavailable.
✅	Passing	—	General	The lookup join returned only exact compatible matches. Unmatched, NULL, rounded, and oversized keys stayed unmatched, and the LEFT JOIN kept their source rows with empty destination values.
✅	Passing	—	General	A table created in one session remained safe while another session tried to remove the extension. The drop was rejected, and both the table and UUID function stayed available.
✅	Passing	—	Drop	The extension was installed, its function worked, and dropping it removed both the catalog entry and the function.
✅	Passing	—	Drop	Trying to remove the extension returned a dependency error, and the table, its row, and the extension function all stayed available.
✅	Passing	—	Extension	The uuid-ossp extension installed in ext_schema, its uuid_nil function worked, and the catalog recorded the extension in that schema.
✅	Passing	—	Extension	The local server rejected pgcrypto as unavailable before creating extension metadata or declared objects. The requested missing-schema check could not run because this extension is not included in the local catalog.
✅	Passing	—	Format	Both formatting calls returned the expected text: Hello Ada Lovelace and Lovelace, Ada.
✅	Passing	—	Format	The identifier and literal results kept their SQL quotes and escaped embedded quote marks correctly.
✅	Passing	—	Label	Calling pg_catalog.lower without an alias returned the value abc and labeled the result column lower.
✅	Passing	—	Length	The database reported character lengths of 12 and 4 and bit lengths of 7 and 9 for the four bounded columns.
✅	Passing	—	Lookup	The lookup joins returned the expected source and destination rows for integer-to-float and numeric-to-integer keys. Left joins also kept unmatched and NULL source rows.
✅	Passing	—	Rev	The format function kept Unicode padding aligned, escaped identifiers and literals safely, rendered NULL correctly, and produced the same result on repeat execution. The generated SQL ran once and stored the intended value.
✅	Passing	—	Rev	A failed drop kept the earlier extension loaded and usable. The IF EXISTS form showed one notice, removed the extension, and made its function unavailable.
✅	Passing	—	Storage	The lookup join returned the matching company row even though the UUID key was stored in a non-primary-key column.
✅	Passing	—	Values	The direct and derived queries showed column1 and column2 and returned both supplied rows: (1, one) and (2, two).
⏸️	Skipped	—	General	Values 999.98 and 999.99 were stored successfully. The value 1000.00 returned a numeric overflow error and was not stored.
⏸️	Skipped	—	General	The failed insert returned a numeric overflow error, left the table empty after rollback, and the retry stored only 12.34 and 56.78.
⏸️	Skipped	—	Lookup	Matching keys returned the expected rows across integer, floating-point, numeric, text, date, UUID, and large-text values. Keys without a converted match were correctly left out of the inner joins.
⏸️	Skipped	—	Lookup	The left join returned the matching destination for source row 1 and kept source rows 2 and 3 with empty destination IDs. The source row count stayed at three.
⏸️	Skipped	—	Lookup	The lookup returned destination 2 when the extra filter allowed it. When the filter matched nothing, the source row remained with an empty destination value.
⏸️	Skipped	—	Lookup	The lookup returned all four expected rows when two large integer keys converted to the same floating-point value. Both source rows matched both destination rows, so no valid match was hidden.
⏸️	Skipped	—	Lookup	The date matched the timestamp at midnight and correctly excluded the later time on the same day.
⏸️	Skipped	—	Numeric	Inserting 1000.00 into a NUMERIC(5,2) column returned SQLSTATE 22003 with a numeric field overflow message, and the invalid row was not saved.
⏸️	Skipped	—	Numeric	Casting 12.345 to NUMERIC(5,2) returned 12.35 and an in-range status.
⏸️	Skipped	—	Rev	Inserting a value that is too large for NUMERIC(5,2) failed with SQLSTATE 22003 and a numeric field overflow message. The server did not return an internal-error code.
⏸️	Skipped	—	Rev	A numeric overflow did not break the database connection. The next insert succeeded, and the saved value was returned correctly.
⏸️	Skipped	—	Rev	The lookup join returned both matching rows, (1, 10) and (1, 11), in the expected order. No duplicate match was lost and no extra row appeared.
⏸️	Skipped	—	Storage	Both source rows matched the expected destination labels in sequence order.
⏸️	Skipped	—	Storage	Each of the three table layouts returned exactly one matching UUID row.

Tip

Reply with @itoqa to send us feedback on this test run.