v0.16.0

Add VALUES statement (#73)

The VALUES statement provides one or more rows as a virtual table:

    SELECT * FROM (VALUES 1, 'foo', TRUE);
    SELECT * FROM (VALUES 1, 'foo', TRUE) AS t1 (abc, col2, "f");

But can also be used as s standalone statement:

    VALUES 'cool', 12.3;

This turned out to be far more involved than I originally throught. It
allowed me to overhaul much of the test suite so that we don't need
to use fake tables anymore.

v0.15.1

Add BETWEEN (#72)

Syntax: X [ NOT ] BETWEEN [ ASYMMETRIC | SYMMETRIC ] Y AND Z

A BETWEEN expression returns TRUE if X is inclusively between
Y and Z. Or, put another way (X >= Y AND Z <= Z).

If SYMMETRIC is provided, the orders of Y and Z are irrelevant. Such
that they will be swapped if Y > Z.

If neither ASYMMETRIC or SYMMETRIC is provided then ASYMMETRIC is
assumed.

v0.15.0

Add transactions (#69)

Transactions are implemented with the START TRANSACTION, COMMIT and ROLLBACK
syntax.

vsql transactions are implemented using Multiversion Concurrency Control (MVCC).
In a nutshell, MVCC maintains multiple copies of rows that are visible to
respective transactions. MVCC is one method to ensure readers and writers do not
block readers or writers. So, unlike SQLite3, there can be multiple concurrent
writing transactions.

By its nature MVCC leaves around copies of rows that have either been deleted or
rolled back. These row versions need to exist until at least the transaction is
finished (COMMIT or ROLLBACK). However, in either case, the rows are not
revisited so they will remain invisible to all other future transactions.

This makes the COMMIT basically zero cost but it requires another process to
clean up expired rows. Since this isn't easily possible or ideal for a
single-process database, vsql performs cleanup on COMMIT and ROLLBACK for any
pages that were modified during the transaction.

The cost of a COMMIT or ROLLBACK should be approximately equal to each other.
However, the cost of an individual COMMIT or ROLLBACK is proportional to the
amount of pages modified and not the number of changes directly.

For this first implementation only READ COMMITTED isolation is used (which is
the default in most other databases). Transaction ID wraparound will be a
problem in the near future to fix. The remaining three isolation levels will be
implemented in the future as well.

v0.14.7

btree: Support transaction IDs (#68)

This refactors the B-tree and paging implementation from only supporting unique keys across the entire tree to now supporting the created/expired transaction IDs as well as allowing for multiple versions of a key.

This is a breaking change to the file format. I decided to do this as an intermediate step because the diff for transaction was getting really large and complex. Implementing the isolation logic now will be easier and I can feel more confident that the B-tree is well tested.

v0.14.6

Add length functions (#67)

CHAR_LENGTH (CHARACTER_LENGTH) and OCTET_LENGTH return the charcater and
byte lengths respectively.

v0.14.5

Added POSITION() (#66)

POSITION(X IN Y) Returns the start of the left most (first) match of one
string within another. 1 will be the smallest index on a match and 0 is
returned if the substring does not exist. Matching is case-sensitive.

Also added a $TEST environment variable which can be used to run a
single test, like:

    TEST=transaction make sql-test

v0.14.4

Migrate to vsql.readthedocs.io (#64)

The documentation has got to a stage where its time to start publishing
it to readthedocs.

v0.14.3

Fix windows binary (#63)

Ths fixed the compilation of the windows binary because the locking code
is only available on *nix systems.

Unfortunately this wasn't caught on CI because we don't bother also
building the windows binary. However, to protect against this happening
in the future we now do.

v0.14.2

Fix open() concurrency in goroutines (#62)

In short, vsql (with the default options) when dealing with concurrent
read/write access to single file provides the following protections:

- Fine: Multiple processes open() the same file.
- Fine: Multiple goroutines sharing an open() on the same file.
- Bad: Multiple goroutines open() the same file.

The connection_test.v fell into the last category. It's interesting it
wasn't picked up by local testing or CI (at least on the first run
before it was merged).

The test has now been updated to use the new "mutex" option and
increased from 10 goroutines x 10 records to 10 goroutines x 100
records.

v0.14.1

Locking for concurrent file access (#61)

As we gear up for transactions, the time has come to make sure
reads/writes are correctly synchronized between multiple connections.

The current implementation is very crude, taking an exclusive lock for
any operation on the file. This will be improved in the future when
locking can be guaranteed on certain portions of the file (sometimes
referred to as "record locking") but for now this will do.

One of the biggest challanges with concurrent access (even just with
read only) is that other connections need to know when the schema
changes (such as a table being created or dropped). Once again, this
implements a fairly rudimentary approach that requires connections to
constantly check a schema version flag in the database header before
any operation. If the schema version has been incremented since last
time the whole schema will have to be loaded again.

Some new features with SQL testing to be able to use concurrent
connections and verbose output to test crash situations.