[masklinn]

> SQLite will gladly store a u64::MAX as a "unix timestamp"

SQLite does not support unsigned integers.

> Try reading that back in any application date/time code and your app probably crashes immediately.

Postgres will happily ingest and produce dates in the 280th millenium, which will also crash your application if its datetime type can’t handle that shrug.

You can add a check constraint that your field passes through SQLite’s datetime functions and it’ll be clamped between the years 0 and 9999. Or you can put in your own limits matching your application layer, or your application’s business logic. That’s what check constrains are for (amongst other things).

[petcat]

> SQLite does not support unsigned integers.

omg you're right. Another example of SQLite's type-flimsyness.

> You can add a check constraint

So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

[masklinn]

> omg you're right. Another example of SQLite's type-flimsyness.

You're just firing on all the bullshit cylinders in your little motorised gish gallop aren't you?

The only RDBMS in widespread use which supports unsigned integers is mysql. Not postgres, not oracle, not sql server, not db2, not snowflake, not databricks.

> So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

Ah yes, the "brittle validation" of actually validating the thing you purported to care about two comments ago. Amazing.