v0.30.1

DELETE: Fix panic when using PRIMARY KEY (#203)

When an index lookup occurs as part of a DELETE, it was not stripping
the qualified identifiers in the row necessary for storage to find the
rows.

This did not effect the equivilent UPDATE, but I have add an extra
test for that anyway.

Fixed #200

v0.30.0

parser: Complete rewrite to LALR (#202)

This replaces the existing Earley parser (which is O(n^3)) with a LALR parser
using Yacc which is an ideal O(n). Even with very short SQL statements, the
existing parser was _really_ slow, so I had to build a query cache as bandaid,
but that has also been removed now.

This refactoring was made possible by adapting yacc from a Go implementation
here: https://github.com/elliotchance/vyac. However, in keeping with the promise
of this repo being completely written in V, the source has been copied to this
repo.

Other notable and breaking changes:

1. Not sure how this worked before, but the query may not specify a catalog in
identity chains (for example, `catalog.schema.table`). The catalog must be set
using `SET CATALOG`.
2. Syntax error messages will be slightly different, but should be a little more
helpful.
3. There are some ambiguities with the SQL grammar, such as trying to decode
what `x IS NOT TRUE` means or differentiating between `COUNT(expr)` vs
`COUNT(*)` due to lookahead limitations. Some special tokens for combinations of
operators and keywords have had to be added for known edge cases, but there are
many remaining conflicts. I suspect these conflicts don't matter as ambiguous
paths should still yield valid results, so these warnings have to be ignored for
now.
4. Fixes a very minor bug where string literals in VALUES might be treated as
`VARCHAR` instead of `CHARACTER` in some cases.
5. Renamed "std_" files with their position number in the standard. This helps
for grouping similar sections and makes lookups easier.

v0.29.4

docs: Fixing CI (#201)

Fixing the "Verify docs" job and running `v fmt` for the new
version.

v0.29.3

v: Update to V 0.4.5 ed7f1ff (#196)

This aggregates the awesome work by @ttytm in #192, #193, #194 and #195.

v0.29.2

fix compilation notice with latest V (#189)

v0.29.1

numbers: Swap NUMERIC and DECIMAL (#187)

I made a mistake, confusing the names of NUMERIC vs DECIMAL. NUMERIC is
actually the exact type and DECIMAL is the more relaxed type, rather
than the other way around. For prosperity, the *only* difference between
these two types in the SQL standard is:

ISO/IEC 9075-2:2016(E), 6.1, <data type>, Syntax Rules:

> 26) NUMERIC specifies the data type exact numeric, with the decimal
> precision and scale specified by the <precision> and <scale>.
>
> 27) DECIMAL specifies the data type exact numeric, with the decimal
> scale specified by the <scale> and the implementation-defined decimal
> precision equal to or greater than the value of the specified
> <precision>.

I have seen this interpreted as: DECIMAL can use more precision (than
specified) if it's more storage efficient or otherwise favorable for the
engine to do so. This is the reasoning behind vsql's DECIMAL
implementation of storing the raw fraction instead of scaling the number
to the exact NUMERIC value.

This also fixes:

1. All exact numeric types (DECIMAL, NUMERIC, SMALLINT, INTEGER and
BIGINT) were being converted to approximate types for comparison (=, >,
etc). They are now compared as exact values.

2. Nowhere does it say say in the standard that exact values should be
zero padded to the precision (ie. 1.200 for NUMERIC(4, 3)). In fact, it
actually specifies that when converting an exact type to a
variable-length character string it should not do that:

ISO/IEC 9075-2:2016(E), 6.13, <cast specification>, General Rules:

> 12) a) i) Let YP be the shortest character string that conforms to the
> definition of <exact numeric literal> in Subclause 5.3, "<literal>",
> whose scale is the same as the scale of SD and whose interpreted value
> is the absolute value of SV.

It could be argued that the string/display values do not need to follow
this same specification as the situation is different. However, I think
it's going to be less confusing long term if we treat these conversions
the same everywhere.

3. Fixed a bug where casting a DECIMAL to DECIMAL of a higher
precision would not result in more actual precision as expected.

v0.29.0

Adding NUMERIC and DECIMAL types (#186)

`NUMERIC` and `DECIMAL` types are used for arbitrary precision exact
numbers. This has a been long in development. It's required several
rewrites and some major changes and improvements to vsql in previous
versions to lay the foundation for these types to be fully integrated as
first class citizens.

Now, number literals that contains a '.' (even if they are a whole
numbers such as `123.`) are treated as `NUMERIC` with the scale and
precision determined from the number. Arithmetic operations can result
in types that are higher in scale and precision, according to the
standard (which is very specific about all of that).

As far as I'm aware vsql is the only SQL database to treat these as
distinct types according to the standard, rather than being aliases of
the same underlying type. In a nutshell, `NUMERIC` and `DECIMAL` are
both stored as fractions, but `NUMERIC` permits any denominator within
range, whereas a `DECIMAL` must have a base 10 denominator. You can
think of `DECIMAL` as having "exactly" the precision specified (i.e good
for currency), but `NUMERIC` has "at least" the precision specified.
Meaning it's possible to `CAST` a `NUMERIC` to a higher precision and
get more decimal places (from the inherent nature of a fraction). The
docs explain this much better, with examples.

Since this does introduce new storage types, a database file version
bump is required but this likely be the last version bump before v1.0.0
is released.

Along with the two new SQL types, there are some functions that work
directly with exact numbers: `ABS`, `CEIL`, `FLOOR` and `MOD`.

SQL Standard E011-03

v0.28.6

language: Added approximate number literals (#185)

This turned out to be a much more involved change that I expected. It
started by adding syntax support for scientific notation (i.e. 32e5) but
ended up overhauling how numbers work in vsql, and solving some major
current and future problems.

All literals in scientific notation are considered `DOUBLE PRECISION`,
that part is pretty straightforward. Furthermore, all approximate
numbers are always formatted in scientific notation, even if smaller
numbers are given a "e0" suffix.

Since this means that exact and approximate numbers now have a different
form we can take a lot of hacky and unreliable guess work out of
literals and implicit casting.

`REAL` and `DOUBLE PRECISION` no longer need to be treated as supertypes
for all other exact types. Which in retrospect makes no sense. The docs
make much more sense on how numbers work and this makes the larger
change of DECIMAL and NUMERIC types coming later much easier to explain
and implement.

v0.28.5

language: Integers now use the smallest exact type (#184)

> ISO/IEC 9075-2:2016(E), 5.3 <literal>:
> 22) The declared type of an <exact numeric literal> ENL is an
> implementation-defined exact numeric type whose scale is the number of
> <digit>s to the right of the <period>. There shall be an exact numeric
> type capable of representing the value of ENL exactly.

I misunderstood "numeric" to mean the NUMERIC type, but clearly they
mean any exact numeric type (which includes SMALLINT, INTEGER and
BIGINT).

Integers will now use the smallest type which makes casting up to
super-types much more straight forward.

Also, SQL tests will not stop on the first failure making it much easier
to cleanup multiple failing tests.

v0.28.4

testing: Directive to expose types (#183)

Use the `/* types */` directive to include each value type in the
output. This is useful to verify that literals or expressions are being
represented as the expected type.