Comment by RedCrowbar

> {value} OR {} = {value}, not {} (OR ≡ ∪), <bool>{} being {} instead of a true boolean value

This is because we define infix OR as

{a OR b | ∀ (a, b) ∈ (A x B)}

Same goes for the cast function.

You may argue that this is confusing, but if you think about everything as a set comprehension, it is way more consistent. For example the `CASE WHEN` example from the post would always return `{}` for empty input, making it obvious.

> but it's explicitly advertised as a feature of EdgeQL that it can return trees (json-like structures)

The tree-like return is not an aspect of a language system, it's a matter of output representation. For example:

    SELECT User { favorites: {name} }

still returns a flat set of User objects. The shape selector `{ ... }` is an annotation that defines how an object is serialized in the output.

> I would ultimately hope for something that can be expressed as a number of function calls and commonly used data structures

This is exactly where we are going. Orthogonality in the underlying language makes it much easier to achieve this.

> and is it as good as PosgreSQL, or MariaDB, or sqlite?

EdgeDB is based on Postgres, we actually transpile EdgeQL to SQL. EXPLAIN and query performance analysis are being worked on.

> in the real world I have to worry more about how performant and robust a thing is under load, than I can worry about programming convenience.

We have posted some benchmarks [1], and more are coming.

[1] https://edgedb.com/blog/edgedb-1-0-alpha-1/