Added `had_true: bool` to `Parser` to track the state of error
encounter, this will be set to `true` once we encounter an error.
If `had_error` is set to true we early return `Ok(None)`.
`FallibleIterator` works in the following way [when `next()`
returns](https://docs.rs/fallible-iterator/latest/fallible_iterator/trai
t.FallibleIterator.html#tymethod.next):
- `Ok(Some(item))` if there's a valid next item.
- `Ok(None)` if the iteration is complete.
- `Err(e)` if there's an error.
I have also added a unit test to check the above contract holds when
parsing `SELECT FROM foo`.
After the fix:
```
limbo> SELECT FROM foo;
× near "FROM": syntax error at (1, 12)
╭────
1 │ SELECT FROM foo;
· ▲
· ╰── syntax error
╰────
```
Closes#865
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#879
Since we are already round robin'ing our `iovecs` in the same way, and
the map will never be larger than MAX_IOVECS, we can remove the cost of
hashing and keep o(1) lookups.
Closes#922
Fixes three bugs:
- When a transaction commits, it should:
1. set the end timestamp of the old version to its own **end
timestamp**,
2. set the begin timestamp of the new version to its own **end
timestamp**
* we were erroneously setting it to the transaction's begin
timestamp. see https://www.cs.cmu.edu/~15721-f24/papers/Hekaton.pdf page
299 diagram.
- When checking for write conflicts, the system should ignore versions
that the transaction cannot see. We were checking for write conflicts
before visibility, allowing a tx to always see the latest committed
version and to always overwrite it, since latest committed versions dont
have an end timestamp.
- When checking for write conflicts, the _presence_ of an end timestamp
should always indicate that it is not the latest version and thus a
newer committed version exists, forcing the transaction to abort.
see https://www.cs.cmu.edu/~15721-f24/papers/Hekaton.pdf page 301
section 2.6. Updating a version
Reviewed-by: Pekka Enberg <penberg@iki.fi>
Closes#927
This is especially useful if you frequently run SQL query like `SELECT *
...`.
## Before
```
limbo> .mode pretty
limbo> select 123 as column1, 'Hello world' as column_2;
+-----+-------------+
| 123 | Hello world |
+-----+-------------+
```
## After
```
limbo> .mode pretty
limbo> select 123 as column1, 'Hello world' as column_2;
+---------+-------------+
| column1 | column_2 |
+---------+-------------+
| 123 | Hello world |
+---------+-------------+
```
---
In the future, if limbo adds a method like `.decl_type()`, we can also
display the data type.
###### DuckDB
```
D select 123 as column1, 'Hello world' as column_2;
┌─────────┬─────────────┐
│ column1 │ column_2 │
│ int32 │ varchar │
├─────────┼─────────────┤
│ 123 │ Hello world │
└─────────┴─────────────┘
```
Closes#925
