feat(go): use updated split_statement with sqlglot

[Mandukhai-Alimaa]

What's Changed

remove override of split_statement.

Had to update the INSERT statements to explicitly define TIME(6) precision. Without it, SQLGlot was parsing the SQL as a generic CAST(x AS TIME). Because the precision wasn't specified in the parsed SQL, the database interpreted the value using its default time precision (3), causing it to round '23:59:59.999999' up to '24:00:00'. Adding the explicit precision ensures the parsed SQL tells the database to preserve all fractional digits.

[lidavidm]

Is that worth filing a bug with sqlglot? If Trino defaults to TIME(6) then I suppose sqlglot should too.

[Mandukhai-Alimaa]

It's not a bug. Trino defaults to TIME(3), not TIME(6). The issue is that Trino behaves differently depending on the SQL syntax. When we write a direct TIME literal like INSERT INTO test_time VALUES (TIME '23:59:59.999999'), Trino can see we are inserting into a TIME(6) column and preserves all 6 fractional digits. However, when we write INSERT INTO test_time VALUES (CAST('23:59:59.999999' AS TIME)), Trino evaluates the CAST first before knowing anything about the target column. It defaults to TIME(3), which rounds 23:59:59.999999 to 23:59:59.999, then to 24:00:00, which overflows to 00:00:00.

The problem occurs because SQLGlot doesn't know the database schema, so when it parses TIME '23:59:59.999999', it translates it to a generic CAST('23:59:59.999999' AS TIME). When Trino receives this generated SQL, it evaluates the CAST independently and applies its TIME(3) default, causing the overflow to midnight. By explicitly specifying TIME(6) precision in the insert statement, SQLGlot can generate the vendor-specific SQL with the correct precision as CAST('23:59:59.999999' AS TIME(6)), which tells Trino to preserve all fractional digits.

[lidavidm]

Ah, thanks, good to know.