Nested INSERT bug

db> CREATE TYPE Foo {CREATE LINK bar -> Object};
CREATE
db> INSERT Foo {bar := (INSERT Foo)};
QueryError: invalid reference to default::Foo: self-referencing INSERTs are not allowed
Hint: Use DETACHED if you meant to refer to an uncorrelated default::Foo set
### INSERT Foo {bar := (INSERT Foo)};
###

This looks like a bug to me. I was under the impression that the thing right after INSERT is supposed to be a type name, not an arbitrary expression, as such there cannot be a problem of self-reference. If memory serves me, we couldn’t actually guarantee that self-references in an INSERT would work (say for use in a subquery selecting some link based on other yet-to-be-inserted data that appears syntactically in the INSERT statement).

As far as I recall this is illegal:

INSERT Bar {
    a := 'data',
    b := .a
};

Am I misunderstanding INSERT?

Just to clarify, the intent is to simple create 2 Foo objects where one is linked to the other. This is not intended or expected to be some sort of self-link.

[elprans]

After some discussion and poking around the realization about nested INSERT is that it does, in fact, obey the general binding rules through its UNLESS CONFLICT clause, which would get very complicated and inconsistent in nested scenarios:

INSERT Tree {
    val := 'i2',
    parent := (
        INSERT Tree {
            val := 'i1',
        } UNLESS CONFLICT ELSE Tree
    ),
} UNLESS CONFLICT ELSE Tree;

Intuitively, the nested ELSE Tree should bind to the nearest INSERT and not to the outer INSERT, but this is inconsistent with the general binding rules of EdgeQL. Thus, I’m reaffirming our position that INSERT isn’t different from other statements in terms of the binding rules.

A possible long-term solution to this problem would be type aliases as in #1578:

WITH ParentTree AS TYPE Tree
INSERT Tree {
    val := 'i2',
    parent := (
        INSERT ParentTree {
            val := 'i1',
        } UNLESS CONFLICT ELSE SELECT ParentTree
    ),
} UNLESS CONFLICT ELSE SELECT Tree;

However, that hinges on a new syntax that isn’t yet implemented, so for now the official recommendation on how to handle simultaneous insertion into a recursive type is to move the nested INSERT statements into a WITH block, as is the general recommendation where recursive types are concerned:

WITH
  parent := (
    INSERT Tree {
      val := 'i1',
    } UNLESS CONFLICT ON .val ELSE (SELECT Tree)
  )
INSERT Tree {
  val := 'i2',
  parent := parent
}
UNLESS CONFLICT ON .val ELSE (SELECT Tree);

[elprans]

I’m reopening this for reconsideration, since there is currently no clean way of INSERT-ing self-referencing objects. To improve the situation we have two options:

1. Allow INSERT Foo {bar := (INSERT Foo)}; without qualifiers, since, as @vpetrovykh rightly pointed out in the comment above, there is no ambiguity as to how to interpret the expression, it must always insert two distinct objects.

2. Allow and require INSERT DETACHED Foo in the nested INSERT. The only benefit of this approach is visual consistency with other statements that already require DETACHED to refer to Foo in the body of its INSERT, most importantly the UPDATE statement.

I now lean toward option 1), as it’s the least verbose option, and visual inconsistency with UPDATE can be explained in the error message and the documentation, whereas forcing the DISTINCT noise word is a price you’ll need to pay every time.

@1st1, thoughts?