v0.22.0

F311-01: CREATE SCHEMA (#111)

This adds support for `F311-01`: `CREATE SCHEMA` from `F311`:
"Schema definition statement" and the respective `DROP SCHEMA` (even
through that's not strictly required for `F311`). For example:

    CREATE SCHEMA warehouse;

    CREATE TABLE warehouse.products (
        title CHARACTER VARYING(100),
        price FLOAT
    );

    DROP SCHEMA warehouse CASCADE;

v0.21.1

F051-06, F051-07, F051-08: Basic dates and times (#110)

Adding support for:

1. F051-06: CURRENT_DATE
2. F051-07: LOCALTIME
3. F051-08: LOCALTIMESTAMP

Starting to migrate docs into a new structure, starting with
"Dates and Times".

v0.21.0

F051: Basic date and time (#109)

In a nutshell, this adds storage support for date/time types and values.
Although, we do not yet support other features such as constants,
functions, comparisons and casting. They can come as a separate features
in the near future.

More specifically, this adds support for:

1. F051-01: `DATE` data type (including support of `DATE` literal).
2. F051-02: `TIME` data type (including support of `TIME` literal) with
fractional seconds precision of at least 0.
3. F051-03: `TIMESTAMP` data type (including support of `TIMESTAMP`
literal) with fractional seconds precision of at least 0 and 6.

The five new distinct data types and their storage requirements are:

1. `DATE` (8 bytes)
2. `TIME(n) WITH TIME ZONE` (10 bytes)
3. `TIME(n) WITHOUT TIME ZONE` or `TIME(n)` (8 bytes)
4. `TIMESTAMP(n) WITH TIME ZONE` (10 bytes)
5. `TIMESTAMP(n) WITHOUT TIME ZONE` or `TIMESTAMP(n)` (8 bytes)

v0.20.1

parser: Fix string interpreted as integer (#108)

This fixes a rather nasty bug that causes the parser to treat strings
that start with a digit to be treated as a number.

The bug existed because the lexer does not include surrounding quotes in
the token value and the code that converts the lexer tokens to earley
columns was testing the value before respecting the token type (which
was out of order from the original Python implementation)

v0.20.0

Adding support for JOINs (#105)

vsql supports three types of JOIN operations:

1. `INNER JOIN` (or, more simply: `JOIN`).
2. `LEFT OUTER JOIN` (or, more simply: `LEFT JOIN`).
3. `RIGHT OUTER JOIN` (or, more simply: `RIGHT JOIN`).

For an `INNER JOIN`, only records that satisfy the ``<condition>`` in
*both* tables will be included.

Whereas `LEFT OUTER JOIN` and `RIGHT OUTER JOIN` will always include all
records from the *left* or *right* table respectively. Any record that
does not match the other side will be given all `NULL` values. The
*left* table is that defined by the `FROM` expressions and the *right*
table is that used in the `JOIN` clause.

This covers almost all of the mandatory SQL features to be "F041 Basic
joined table" compliant. The only feature that's missing is F041-07,
which is the ability to have more than JOIN clause.

There are also some other small improvements:

1. The syntax now supports a "qualified asterisk". This is the ability
to include all columns for a specific relation, such as "SELECT foo.*".

2. Since up until now we were only really dealing with one table there
was little reason for the syntax to allow identifier chains (even though
the planner supports it). An example of an identifier chain is "foo.bar"
and is now supported in expressions.

v0.19.4

planner: Is now table aware (#104)

Even though the planner only deals with one real table (subqueries do
not count) it's important that internally is treats all columns with
respect to the table they belong to. This allows for multiple tables in
the future (JOINs, etc).

This was a lot more involved that I thought it would be and has led to
adding a bunch of new hacks and complexity to the planner. At this point
we need to start really thinking about rewriting the planner soon.

Some unavoidable side affects (but actually all good) from this
refactoring:

1. The EXPLAIN plan now shows the table name in expressions, such as
"FOO.ID" instead of just "ID". This is slightly more verbose but
ultimately better overall.

2. The SELECT expressions are no longer evaluated at the time the data
is pulled out of the table (during the first TableOperation step). All
columns are extracted and a separate new EXPR step is executed at the
end. This means that we have all fields available and don't have to do
any trickery to include virtual fields as part of the plan (such as
"$WHERE") or limit GROUP BY to fields that must also be present in the
SELECT expressions.

3. The GROUP BY pretty much had to be rewritten. In a nutshell, GROUP BY
will use the expression itself (such as "COUNT(*)") as it's internal
column name allowing for more flexibility.

v0.19.3

Fixing linux binaries (#99)

This also adds docs as a verifying step to the CI process (to make sure
there are no warnings or errors).

Fixes #98
Fixes #97

v0.19.2

Documentation fixes (#96)

- Added a "SQL Compliance" page (that is not yet complete) but it enough
to get the ball rolling on fleshing out exactly which features are
missing before we can claim a v1.0.0

- Updated the README to be a lot more helpful with quick links.

- Fixed some formatting that was previously breaking the build.

- Added a "Transactions" and "Installing & Updating" documentation
pages.

- Added the readthedocs.yaml configuration file which is the recommended
way and also cleaned up the existing conf files and pinned the python
dependencies (as recommended).

v0.19.1

cli: Fix crash on missing args (#94)

Fix crash that occurs when running vsql cli without a .vsql file cmd argument.

v0.19.0

Add GROUP BY (#92)

The `GROUP BY` clause is used to group rows such that aggregation
functions can be applied.

There are 5 functions supported: AVG, COUNT, MAX, MIN and SUM and these
are limited to DOUBLE PRECISION versions at the moment.