v0.25.0

Added `in` and `out` commands (#131)

`vsql in` will execute a SQL file and `vsql out` can be used to dump the
structure and data from a database in SQL format. These are also useful
when converting data to and from other databases.

The commands are designed to be simple and provide a means to make a
lossless copy (or a backup) of a database without any other options:

    vsql out mydb.vsql > mydb.sql
    vsql in mydb.vsql < mydb.sql

This is also especially important if there are changes to the vsql file
format in the future. To be able to quickly and easily recreate the
database.

You can find more CLI options and documentation for these commands here:
https://vsql.readthedocs.io/en/latest/cli.html

To facilitate testing, there is now a 5th test suite called
"CLI Tests" which are written as shell scripts and executed along with
the other suites. This provides a lot of flexibility in testing CLI
options, exit codes, outputs, etc. You can read how CLI Tests work here:
https://vsql.readthedocs.io/en/latest/testing.html#cli

v0.24.4

All tables must belong to a schema (#129)

The PUBLIC schema is now created when the database is created and any
table that does not qualify a schema is placed into the PUBLIC schema.

Have also added Connection.schemas() and Connection.schema_tables() for
introspection.

v0.24.3

Documentation for V Client Library (#128)

There is now a "V Client Library" page to properly document the public
interface when using V to interact with vsql.

To make this easier, a new feature has been created that will extract
"snippets" from comments in V code and put them into `snippets.rst` for
reference in the documentation. This will ensure that we only need to
keep the docs in one place right within the code.

v0.24.2

Split vsql subcommands (#126)

This splits each subcommand of vsql into its own V file. There will be
new subcommands coming in the future and this will be cleaner.

There is no change to functionality, other than you must use `vsql cli`
explicitly now (rather than the implicit `vsql` without a subcommand).

The Makefile has been updated to put the binary in bin/ which is a more
regular location than in cmd/ previously.

v0.24.1

Non-reserved words can be used as identifiers (#127)

Previously all <key words> (which includes reserved and non-reserved
words) were disallowed as identifiers. Looking at the SQL standard more
closely, it does explicitly state that reserved words cannot be regular
identifiers using and case, but nowhere does it state that non-reserved
words are not allowed to be used as identifiers.

This is an import distinction because `public` is a non-reserved word
and we intend to use it for the default schema and also for
compatibility with the same schema in PostgreSQL.

Also, comments can now be placed in `grammar.bnf` with a `#` at the
start of the line (not within a line).

See #103

v0.24.0

Large object storage (#125)

vsql now supports storing objects (rows, tables, etc) larger than a page
(which previously was a serious limitation). This happens entirely
transparently on the B-tree implementation where larger objects are
split (and reconstructed) to and from new `B` (blob) and `F` (fragment)
objects.

This is a breaking change to the file format. Some other notable
improvements:

- Documentation now has Excalidraw diagrams. The "File Format" page has
been totally overhauled and is a lot easier to understand and much
nicer to look at: https://vsql.readthedocs.io/en/latest/file-format.html

- Added "Limitations" page. Among which, a vsql file - in theory - can
hold up to 128PB (wholly untested, of course).

- Page splitting now has a heavy bias towards filling the left page as
much as possible (rather than even splitting). We prefer the left page
to be a full as possible because the keys are sequential, so in the case
of lots of sequential inserts it can pack the data more tightly and
causes less page splits as new data is inserted.

- Added another B-tree test for testing 100k sequential inserts/deletes
and improved the existing random insert/remove test matrix from just 48
byte objects to also include 148 byte objects (one object per page) and
348 byte objects (always using blob storage).

Fixes #43

v0.23.2

F261-04: COALESCE function (#124)

`COALESCE` returns the first value that is not `NULL`. If all values are
`NULL` then `NULL` is also returned.

v0.23.1

F261-03: NULLIF function (#123)

`NULLIF(X, Y)`: If `X` and `Y` are equal, `NULL` will be returned.
Otherwise `X` is returned.

v0.23.0

F201: CAST function (#122)

The CAST function is used to explicitly change a value to another type.
If the type conversion is not possible, a SQLSTATE 42846, 22001 or 22003
is raised. The last two states are special cases where the conversion is
valid, but the type is not large enough (for strings) or causes an
overflow (for numbers) respectively.

Casting between types might sound fairly trivial, but it's actually is a
major undertaking because up until now vsql has used strict-ish typing.
That is, types that are similar enough the share the same underlying
value (like SMALLINT vs INTEGER vs BIGINT are all stored in an i64
property). This would avoid any overflow checking and worked in a lot of
cases by "coincidence" with extra branches needing to categorize all
these types.

Now, types for operations can be much stricter. Making adding new types
much easier and safer in the future.

- Added SQLSTATE 22001 "string data right truncation". This means a
character value is trying to be converted to a type that is not large
enough to store it. This doesn't just apply to CAST, but also protects
against the same previously unprotected rules for INSERT and UPDATE.

- Added SQLSTATE 42846 "cannot coerce". The general error when a value
cannot be CAST to another type because it is incompatible.

- Fixed bug where CHARCATER(n) types would not zero pad values smaller
than when the length is less than n (as the SQL standard says).

- Many fixes for dates and times that allow conversion between other
date and time types with the correct semantics, rather than the
ultra-strict parsing we previously only allowed for. For example,
inserting a TIMESTAMP WITHOUT TIME ZONE is now permitted and appends the
correct local time zone if inserted into a TIMESTAMP WITH TIME ZONE.

- Lots of documentation cleanup around types and casting rules.

v0.22.6

Improvements for integers (#120)

Integer constants are now always parsed as BIGINT and integer types
(`SMALLINT`, `INTEGER` and `BIGINT`) are stored as an i64 in the Value
rather than storing them in the existing f64 which will lose precision
of the integer.

This allows use to raise a new SQLSTATE 22003 "numeric value out of
range" in most cases. However, this is not entirely complete as the
minimum value for BIGINT cannot be encoded corrected. See #116.