Error 1105: type time.Time not supported as bind var

[nustiueudinastea]

Using Dolt in embedded mode via the github.com/dolthub/driver library, and when running a migration using https://github.com/bokwoon95/sqddl, I get the following error:

Error 1105: type time.Time not supported as bind var: 2024-03-29 17:34:04.080386 +0200 EET m=+7.550176251
INSERT INTO sqddl_history (filename, checksum, started_at, time_taken_ns, success) VALUES ('protos_01_tables.sql', '', '2024-03-29 15:34:04', 48969292, FALSE) ON DUPLICATE KEY UPDATE checksum = VALUES(checksum), started_at = VALUES(started_at), time_taken_ns = VALUES(time_taken_ns), success = VALUES(success)

Running that SQL via the dolt sql command works as expected on the same database. Let me know if I can be of further help to troubleshoot this.

[jycor]

Hey @nustiueudinastea, thanks for reporting this issue!
We were able to get a fix for datetime and timestamp types, and in the process discovered some issues with decimals.

This fix has been merged to vitess and gms main, and is making its way to dolt main.
Expect a release with the fix early next week, likely Monday.

[nustiueudinastea]

Awesome, thank you! Always impressed with the speed you guys manage to fix issues.

[nustiueudinastea]

hey @jycor, I used the new dolt release with my code and the initial issue is fixed, but now I get a different error:

Error 1105: Incorrect datetime value: '2024-04-03 13:23:44.506434 +0300 EEST m=+4.349756251'

If I format the time value with something like this: x.Time.UTC().Format("2006-01-02 15:04:05"), I don't get this error anymore.

Not sure if this is expected or not so it's worth mentioning it here, since probably the same vitess code is throwing this error.

[fulghum]

Hi @nustiueudinastea, thank you for following up and reporting this. 🙏 It looks like MySQL has more permissive behavior than Dolt when parsing datetime literals. MySQL does parse '2024-04-03 13:23:44.506434 +0300 EEST m=+4.349756251', but it also issues a couple of warnings that it drops the +0300 EEST m=+4.349756251 part.

Dolt should match this same behavior, so I created a new issue to track this: #7690

Feel free to add more context on the new datetime issue. It sounds like you found a workaround for your immediate issue, but let us know if you're still blocked on this and we are happy to find a way to help.