When an alias is provided, it completely hides the actual name of the table or function; for example given FROM foo AS f, the remainder of the SELECT must refer to this FROM item as f not foo.

from https://www.postgresql.org/docs/13/sql-select.html

Currently the flow of a query is

Query -> Lexer turns string into tokens -> Parser parses tokens into abstract syntax tree structs, or basically commands -> Evaluator evaluates command

Typically, database systems have at least one component between the parser and the evaluator: a query planner. It generates a query plan, which tells the evaluator/runtime how to actually run the command in the AST on the specified set of data in the query.

Distinguish between a row (a tuple, really) as stored on the backend and a row as it is being built up for returning. Currently the object.Row struct has a SortByValues slice which is used to determine where this row should end after sorting. But the stored tuple shouldn't need to know about this.

Possible solution: Define object.Tuple struct? Store row on backend as a []object.Object instead? (or could alias Tuple to []object.Object.

This came up (again) when I started working on persistent backend (issue #9)

Could call them left join and right join, in Postgres the outer keyword is optional

Like toydb?

We sometimes check the peek, sometimes the current

>> create table nums (n int)
OK
>> insert into nums values (1)
OK
>> insert into nums values (2)
OK
>> select nums.n, n.n from nums, nums n
n n
1 1
1 1
2 2
2 2

but if we create another table that's equal, we get

>> create table mums (m int)
OK
>> insert into mums values (1)
OK
>> insert into mums values (2)
OK
>> select n, m from nums, mums
n m
1 1
1 2
2 1
2 2

which is also what Postgres returns on a self-join

# create table nums (n int);
CREATE TABLE
# insert into nums values (1), (2);
INSERT 0 2
# select * from nums, nums n;
 n | n
---+---
 1 | 1
 1 | 2
 2 | 1
 2 | 2