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.

v0.28.3

testing: Better support for Unicode and whitespace characters (#181)

testing: Better support for Unicode and white space characters

Unicode characters can be placed in tests as regular characters.
However, due to editors/IDEs sometimes handling white space in different
ways you can add a placeholder for a specific Unicode point using
`<U+####>`.

This will be replaced with the correct character before the test runs.
This is only a feature of SQL Tests, so will not work in any other
context.

The SQL standard names specific white space characters that must be
valid separators, we already supported this but now they are codified
into tests using the new syntax above.

v0.28.2

testing: Comments are now supported (#182)

Not sure why it took me so long to implement, but you can now add
comments to tests by using `-- #`.

v0.28.1

v: Update for V 0.4.3 ed754cf (#177)

This is mostly just formatting changes, but there is one remaining notice that cannot be fixed at this time: vlang/v#20245