Use native postgres boolean type instead of integers

[abitofevrything]

Makes it so that databases connected to postgresql will use the boolean type for boolean columns, instead of integers mapped to booleans as they are in sqlite.

These changes were made to be non-breaking but could use some cleanup in the next major release - mainly changing the SqlTypes methods to get the current dialect from somewhere else than an optional positional parameter.

Closes #2113

[abitofevrything]

Converted to draft as this PR has issues with backwards compatibility - databases generated before this PR would not be compatible with the contents of this PR.

I'll work on allowing both integer and boolean columns to represent booleans in postgres, and users can migrate simply by changing the column type.

[simolus3]

databases generated before this PR would not be compatible with the contents of this PR.

You mean the generated database code, right? I think this is fine as long we keep the dependency constraints between drift and drift_dev consistent. The current contract is that we can make "breaking" changes in minor drift versions as long as the generator with the same minor version will generate correct code. It means that users will have to re-run build_runner build after upgrading their dependencies, but at least drift and drift_dev don't get out-of-sync.

[abitofevrything]

No, I mean the actual database - the column type from before this PR would still be integer which is incompatible.

Since postgres accepts 1 and 0 as Boolean literals, it would be possible to be backwards compatible if it weren't for the postgres library only accepting bool for Boolean arguments and int for integer arguments in queries - other than that, reading from the db and constants embedded in the query as literals are compatible with both column types, so arguments are the only real blocker.

[abitofevrything]

It would be easy for users to migrate though, simply ALTER TABLE tbl_name ALTER COLUMN old_integer_boolean_column DROP CHECK SET TYPE boolean USING integer::boolean;, or something along those lines (wrote that from memory).

[simolus3]

Oh right, of course. Given that our support for postgres is still somewhat experimental, I think that shouldn't be a problem either. I think it's better to just do this right now instead of adding (and testing and maintaining) a build option just to get the broken behavior.

[AlexKenbo]

It would be easy for users to migrate though, simply ALTER TABLE tbl_name ALTER COLUMN old_integer_boolean_column DROP CHECK SET TYPE boolean USING integer::boolean;, or something along those lines (wrote that from memory).

Can you tell me if we are just starting out, can we use your commite right away?
We have been writing backends in Dart for 1.5 years, but we don't work with SQL directly. We work via Hasura :)

Now the application has grown and we need more control on the backend and we don't want to leave Dart for Java.

We already had a nice experience with Moor. We want to try it with Postgres as well.
We're in business and we want to move in this month, hopefully all will be good.

And ideally we will join in on the package.

I'd like your opinion @simolus3 - why is this still experimental and what might we encounter?
We already have experience writing complex queries and embedded SQL procedures.

[abitofevrything]

Yes, this PR is in a working state. You just need to migrate existing databases, both the actual database contents and the generated database file to use it though.

I'll reopen it later, as if backwards compatibility isn't a huge concern then there is no reason for this to be kept as a draft.

[abitofevrything]

After a bit of experimenting, this is the SQL migration query for old integer columns to the new boolean columns:

ALTER TABLE tbl_name DROP CONSTRAINT col_constraint, ALTER COLUMN col_name TYPE boolean USING col_name::boolean;

Where:

• tbl_name is the name of the table containing the column
• col_constraint is the name of the old CHECK value IN (0, 1) constraint (can be found with \d+ from psql, generally looks like $tblName_$colName_check)
• col_name is the name of the column to change.

Run that query in a migration for every boolean column in your database, and that's all the migration done.

[simolus3]

I like the idea and the approach! My only concern is the increased code size, but I think we can fix that.

[simolus3]

Thank you for your contribution!

[simolus3]

@abitofevrything To reduce the size of the generated code, dialects for which we generate code now need to be enabled (in drift 2.11.0). If you only need postgres support, you can use dialect: postgres in your build.yaml. If you need database code that works on sqlite3 and on postgres as well, you can use this setup. Without that option, the postgres-specific types and constraints would be removed from generated code in the latest drift version.