fix: Error on missing nested SELECT.from.SELECT.from.ref

[danjoa]

• fixes [REGRESSION] db-service aggregation query throws error #1112 (comment) ?
• @patricebender pls double check

[johannes-vogel]

I think we have to add a test for this, before this release it was

...(transformedQuery.SELECT.from.ref || /* subq in from */ transformedQuery.SELECT.from.target.name),

however, i don't know how it worked ...

[hakimio]

@johannes-vogel before it was:

...(transformedQuery.SELECT.from.ref || /* subq in from */ [transformedQuery.SELECT.from.target.name]),

0828c25#diff-3406bdae94230d4664b3a51d7efa5f3807f2a43095a9089ff018c5a5faf7ca3aL803-L806

It worked because of ...[transformedQuery.SELECT.from.target.name].

[johannes-vogel]

It worked because of ...[transformedQuery.SELECT.from.target.name].

This part I understood. However, a query is not designed to have a target in SELECT.from.

[danjoa]

Exactly I wondered how that would have worked before. We really should have a test

[hakimio]

@johannes-vogel here is the answer:

if we select from <subquery> we do not have a SELECT.from.ref but the <subquery> has a .target because it has been inferred properly.

Use the name of the .target for building the correlated subquery, instead of dumping.

#709