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.

v0.22.5

BOOLEAN type and logical fixes (#118)

NULL and UNKNOWN mean the same thing and are interchangeable. Also,
fixed some bugs related to using UNKNOWN in logical operations and added
the "IS [ NOT ] { TRUE | FALSE | UNKOWN }" expression.

Finally, updated docs for boolean type and logic.

v0.22.4

Cross platform file support (#117)

The file format is now consistent to always use big-endian so it will be
portable across architectures and operating systems.

Fixes #76

v0.22.3

Overhaul NULL implementation (#115)

This is a fairly significant refactor to overhaul how NULLs are
represented internally and includes some BREAKING changes to the file
format (which has been bumped to v7).

Previously, a NULL value was given an exclusive SQL type (so it didn't
have an actual type). This caused some problems with the fact that NULLs
have to be typed in the SQL standard.

In the process, it's created a more robust type system (which is
important for CAST which will come later) and fixes at least one bug
with NULL booleans and timestamps.

v0.22.2

E021-09: TRIM function (#114)

`TRIM` can be constructed in several forms:

    TRIM(
      [ [ { LEADING | TRAILING | BOTH } ] [ trim_character ] FROM ]
      trim_source
    )

If `LEADING`, `TRAILING` or `BOTH` is not provided, `BOTH` is used.

If `trim_character` is not provided, a space (`' '`) is used.

    VALUES TRIM('  hello world ');
    -- COL1: hello world

    VALUES TRIM('a' FROM 'aaababccaa');
    -- COL1: babcc

    VALUES TRIM(LEADING 'a' FROM 'aaababccaa');
    -- COL1: babccaa

    VALUES TRIM(TRAILING 'a' FROM 'aaababccaa');
    -- COL1: aaababcc

v0.22.1

E021-06: SUBSTRING function (#113)

`SUBSTRING` can be constructed in several forms:

  SUBSTRING(
    value
    FROM start_position
    [ FOR string_length ]
    [ USING { CHARACTERS | OCTETS } ]
  )

`start_position` starts at 1 for the first character or byte. If
`start_position` is out of bounds (either before the start or after the
end) the returned value will be empty.

If `string_length` is not provided, all characters or bytes until the
end will be included. Otherwise, only `string_length` will be included.
If `string_length` goes beyond the end of the string it will only be
used until the end.

If `CHARACTERS` is specified the `start_position` and `string_length`
will count in characters (this works with multibyte characters) whereas
`OCTETS` will strictly count in bytes. If `USING` is not provided,
`CHARACTERS` will be used.