AnyhowStep

It all boils down to what this library is really intended to do. The number 1 concern is to have consistent behavior across all supported databases, as long as the...

In particular, the timestampAddXxx() tests. These are prime candidates for being moved to the extended test suite. Maybe have a few dozen cases kept in the regular test suite

On MySQL, PostgreSQL, SQLite, the following, ```sql CREATE TABLE test ( testId INTEGER , testVal INTEGER, CONSTRAINT u UNIQUE (testVal) ); INSERT INTO test(testId, testVal) VALUES (NULL, NULL), (NULL, NULL);...

`updateAndFetch(ZeroOr)OneByXxx()` methods should not allow setting a primary/candidate key column to `null` It should be fine for other columns (like a non-key column of a super key) to be set...

We should do #210 first

> I wonder what units that precision value has... bits? Decimal places? Significant figures? Ah well, someone smart will figure that out. This is really important. Particularly for division, *siginificant...

With REPEATABLE_READ, you can still have deadlocks and timeouts, but this should only happen with **long-lived** transactions. And, usually, you shouldn't have long-lived transactions. They should be small and quick....

However, the SQL standard does say the default is SERIALIZABLE... And MySQL uses REPEATABLE_READ, while PostgresQL uses READ_COMMITTED...

Maybe transactions in the library shouldn't have a default isolation level at all, and should force users to carefully think about the isolation level they want

Should add this to the documentation, ``` 1. [Declaring candidate keys](declaring-candidate-keys.md) ```