Comment by RedCrowbar

>> Why not bottom, or are containers not covariant? I'm worried that we're not clear about the difference between variables and values.

Yes, `{}` is inferred as `anytype`, but we chose to restrict its use in output for interoperability reasons: the output of a query must be of a concrete, known type.

>> Strictly speaking, EdgeQL sets are multisets [1] > Like nulls, this is another broken aspects of SQL.

From the purity standpoint, yes, but in practice, duplicate values are either expected, or too expensive to eliminate. That said there is a `DISTINCT` [1] aggregate.

> * It conflates types with relation variables

Not exactly. We do use the same symbol to denote a type, and a relation that it represents, but the context of which is which is always clear (i.e. Foo in a cast expression is always a type), but Foo in a regular expression is always a relvar.

> * It's using links rather than foreign key constraints

Links are an abstraction over a foreign key. In the vast majority of cases foreign keys are implemented as 'some_id' -> 'id' anyway. If you want a custom foreign key, you can set an expression constraint on a property or a link.

> * It doesn't seem like the user can even specify a candidate key

type Foo { constraint exclusive on ((.name, .last_name)) }

> * Which is why the "id" field is magical and special

See RM proscription 15 in the Third Manifesto [2]

> * Constraints only seem to apply to scalars

They aren't, see above.

[1] https://edgedb.com/docs/edgeql/funcops/set#operator::DISTINC... [2] https://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf