Michael J. Sullivan

Oh, like with #4302, it has the problem that some of the conflicting objects might have a different type, also

Yeah, I actually meant to update this issue with that suggestion yesterday, since I just merged https://github.com/edgedb/edgedb/pull/4106, which makes us actually generate `id`s outside of the actual INSERT

Something bizarre is happening. The failure seems to reproduce in CI; I haven't reproed it locally, and I can't understand a change in `pgsql` could cause a stack overflow during...

All of queries in the follow-up posts have been fixed, I believe by #3987. The original query is still broken though. ("more than one row returned by a subquery used...

I think that the particular issue here is that we ought to be materializing `linkprop`, and aren't. Possibly related to `test_edgeql_scope_ref_outer_06b`

Well, good news: in 2.0, we instead produce an ISE when passing this sort of `INSERT` to `array_agg`! (At least sort of this is actually good news---an ISE is better...

There's a deep connection here to https://github.com/edgedb/edgedb/issues/3030, also `array_agg`ing an insert and then trying to access the elements is going to be really hairy to get to work properly

No update on this. Passing the results of inserts to functions is kind of a mess.

`delete schema::Migration` ought to produce a nice error message. Currently, it succeeds. Fortunately, it never actually deletes anything, because there is an access policy on it that causes objects to...

Could you check if #3927 fixed it? On Wed, Jun 8, 2022 at 7:29 PM Colin McDonnell ***@***.***> wrote: > A simple group statement implemented with the query builder may...