The SQLDelight SQLite documentation showcases the usage of (what is essentially) preinstalled ColumnAdapter's. For example, the following (user-specified column adapters are not required/allowed):

CREATE TABLE some_types (
    some_short INTEGER AS Short,
    som_boolean INTEGER AS Boolean
)

This makes sense for SQLite, where there isn't a SMALLINT that would automatically map to kotlin.Short, or BOOLEAN that would automatically map to kotlin.Boolean. With dialects that do support these types (either through pseudo or actual types), I don't think it makes sense to have these preinstalled adapters for these dialects as it promotes the abuse of using the wrong underlying SQL type (e.g., using INT AS Boolean instead of BOOLEAN in PostgreSQL).

I'm a bit hesitant of this proposal, purely because of its implementation. As sqldelight/sql-psi#155 advocates for having dialect specific things in their own sql-psi module and making SQLDelight dialect agnostic, it's not obvious where the specification of preinstalled ColumnAdapter's only for SQLite should go:

1. Have the logic reside in the SQLite dialect specific sql-psi module doesn't make sense, as ColumnAdapters are an SQLDelight construct, and doesn't really relate semantically to what sql-psi is trying to solve.
2. Have the logic reside in SQLDelight wouldn't work, because now we're doing dialect specific things in SQLDelight (something we would like to avoid in the future).

Personally, I'd do away with default column adapters, and have the user explicitly hook the adapter up with the database like they do for their own custom ColumnAdapter's. SQLDelight could provide a set of commonly used ColumnAdapter's (e.g., IntColumnAdapter, BooleanColumnAdapter). This idea would mean that non-SQLite dialects would have access to this suite of ColumnAdapter's, but the adapters could ultimately be put into a separate module with a strong suggestion in its description to only use them if the dialect the user is using doesn't have an SQL type that would otherwise return the same Java type they desire. As was said, this wouldn't address the initial issue 100%, but would make doing the wrong thing by accident a bit harder.

Here's a (temporary) backwards compatible prototype of what I was discussing (branch). The final form would look like this (branch). I can make a PR for either one of these if there's interest.

WDYT?