Fixed Issue #3330

[Hydrocharged]

Fixes #3330.

Stacked on #3352.

[itoqa]

Commit: 705b2d8: 11 test cases ran, 11 passed ✅.

Summary

Coverage spans normal trigger metadata retrieval and compatibility with existing database metadata, plus edge cases around unsupported events, argument quoting, action ordering, database isolation, empty catalogs, and cleanup after table removal. The results indicate healthy behavior across these core data-access and lifecycle scenarios.

Safe to merge — all exercised behaviors passed, with no regressions or PR-attributable failures identified. No merge-blocking risk is evident from this run.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The trigger catalog rejected TRUNCATE as unsupported and returned clean rows for DELETE, INSERT, and UPDATE. Supported events kept contiguous action-order values with no empty event row.
✅	—	General	The trigger catalog kept empty and missing arguments separate and preserved commas, quotes, and backslashes after reconnecting.
✅	—	General	Adding a trigger to the middle of the INSERT group produced order values 1, 2, and 3, while the unrelated DELETE and UPDATE groups stayed at 1.
✅	—	General	Each database returned only its own trigger row, including its catalog name, event type, and function arguments.
✅	—	General	The database client read all 17 trigger metadata columns without errors. Filtering, selecting specific columns, and sorting returned the expected trigger values.
✅	—	Metadata	The existing constraint and sequence metadata queries still work, and the new trigger metadata query also returns successfully with its normal columns.
✅	—	Rev	The trigger catalog returned one complete row each for INSERT, UPDATE, and DELETE, with the right table, row orientation, and timing.
✅	—	Rev	The trigger was listed before the table was dropped, then disappeared after the table was recreated without the trigger. No leftover row with the old trigger name remained anywhere in the trigger metadata.
✅	—	Rev	An empty database exposes the trigger catalog with all expected columns, returns no trigger rows, and leaves other catalog queries working.
✅	—	Triggers	The database returned all 17 metadata columns and four correct rows for the test triggers.
✅	—	Triggers	The trigger metadata query returned all four expected rows with the right events, order values, function arguments, row orientation, and timing.

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	19855	19867
Failures	22235	22223
Partial Successes1	5440	5441

	Main	PR
Successful	47.1727%	47.2012%
Failures	52.8273%	52.7988%

${\color{lightgreen}Progressions (11)}$

aggregates

QUERY: insert into bytea_test_table values(decode('ff','hex'));

QUERY: insert into bytea_test_table values(decode('aa','hex'));

constraints

QUERY: SELECT * FROM DEFAULTEXPR_TBL;

strings

QUERY: insert into toasttest values(decode(repeat('1234567890',10000),'escape'));

QUERY: insert into toasttest values(decode(repeat('1234567890',10000),'escape'));

QUERY: insert into toasttest values(decode(repeat('1234567890',10000),'escape'));

QUERY: insert into toasttest values(decode(repeat('1234567890',10000),'escape'));

QUERY: SELECT decode('1234567890abcdef00', 'hex');

QUERY: SELECT decode(encode(('\x' || repeat('1234567890abcdef0001', 7))::bytea,
                     'base64'), 'base64');

QUERY: SELECT decode(encode('\x1234567890abcdef00', 'escape'), 'escape');

triggers

QUERY: SELECT trigger_name, event_manipulation, event_object_schema, event_object_table,
       action_order, action_condition, action_orientation, action_timing,
       action_reference_old_table, action_reference_new_table
  FROM information_schema.triggers
  WHERE event_object_table in ('pkeys', 'fkeys', 'fkeys2')
  ORDER BY trigger_name COLLATE "C", 2;

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

[coffeegoddd]

@Hydrocharged DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.43	2.43	0.0
groupby_scan_postgres	77.19	77.19	0.0
index_join_postgres	2.26	2.22	-1.77
index_join_scan_postgres	1.61	1.61	0.0
index_scan_postgres	475.79	458.96	-3.54
oltp_point_select	0.37	0.37	0.0
oltp_read_only	6.43	6.32	-1.71
select_random_points	0.72	0.72	0.0
select_random_ranges	1.04	1.04	0.0
table_scan_postgres	458.96	458.96	0.0
types_table_scan_postgres	1149.76	1170.65	1.82

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.36	3.36	0.0
oltp_read_write	13.46	13.46	0.0
oltp_update_index	3.55	3.55	0.0
oltp_update_non_index	3.25	3.25	0.0
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0

[zachmu]

Change looks fine, see comments

[zachmu]

Move next to other information_schema tests

[zachmu]

No tests of this

[zachmu]

This worries me, what does this mean