DML in cast_expr

[aljazerzen]

Closes #5050

[aljazerzen]

@msullivan I'm not sure if this is the correct way to do it.

I had a problem where DML within iteration was producing this:

    WITH
    source_rel AS
        ((
            SELECT *, ctid FROM "the_link_table"
            -- this ctid should be used as the iterator
        )),
    "iter~1" AS
        ((
            FROM source_rel AS "source_rel~1"
            CROSS JOIN LATERAL (
                SELECT/*<pg.SelectStmt at 0x7f82c0915f10>*/
                    "source_rel~1"."hell" AS "hell_value~1",
                    edgedb.uuid_generate_v4() AS "hell_iterator~1"
                    -- this uuid_generate call should not be here.
                    -- ctid should be used instead.
                    -- I inject its path and rel vars so it would be picked up
                    -- but the code above overriddes it.
                    -- So I've disabled that.
                WHERE
                    ("source_rel~1"."hell" IS NOT NULL)
            ) AS "Hello~3"
            SELECT/*<pg.SelectStmt at 0x7f82c0914110>*/
                "Hello~3"."hell_iterator~1" AS "hell_iterator~2"
        )),
    "ins_contents~1" AS
        (...)
    ...

[msullivan]

This seems plausible, though I'll ponder it a bit.
(I would restructure it so that the put_path_var is in the conditional instead of having an early return.)

[aljazerzen]

So I have the following DDL:

alter type Base {
    alter link foo {
        alter property bar set type int32;
    };
};

I set external_rels for Base, Base::foo and Base::foo@.
But on lookup for set with path_id (default::Base).>foo[IS default::Child]@bar[IS std::int64], I'm not finding it in external_rels.

This should happen here: https://github.com/edgedb/edgedb/blob/7a145a9596fd21c4d5a330839459947e0582e79a/edb/pgsql/compiler/relgen.py#L426-L428

[msullivan]

Huh, you mean external_rels is getting cleared somewhere?

[aljazerzen]

I give up. I might come back when I understand how our backend compiler works better.