There's a slight discrepancy on how SQLDelight's dialect is set and what database Hikari uses. The former is set at compile time, and the later is set at runtime. This can lead to weird problems even if there is effort to keep them in sync. All it takes is for us to compile with one combo (e.g., both on SQLite) and then run with another (e.g., both on PostgreSQL).
I'd like to solve this by keeping the SQL dialect to a minimum, ensuring there are no weird incompatibilities. But to ensure it stays this way in the future, we should be testing our schema and migrations with all dialects we accept.
There's a slight discrepancy on how SQLDelight's dialect is set and what database Hikari uses. The former is set at compile time, and the later is set at runtime. This can lead to weird problems even if there is effort to keep them in sync. All it takes is for us to compile with one combo (e.g., both on SQLite) and then run with another (e.g., both on PostgreSQL).
I'd like to solve this by keeping the SQL dialect to a minimum, ensuring there are no weird incompatibilities. But to ensure it stays this way in the future, we should be testing our schema and migrations with all dialects we accept.