Inconsistent behavior of LakeBridge transpiler for similar scripts

[Satyam_Patel]

Hi Everyone,

I am testing the LakeBridge prototype and noticed inconsistent behavior when converting stored procedures.

• For simple scripts, the conversion is correct.

• But for medium/complex scripts, especially those with multiple LEFT JOINs and column extractions, the transpiler sometimes produces unexpected results.

Example behavior I saw:

• The original SQL Server stored procedure was ~80 lines.

• After conversion, the output script became ~1000 lines, mostly filled with repeated SET … = (SELECT …) blocks instead of a single structured query.

• In one case, two scripts with a very similar pattern behaved differently — one converted correctly, while the other expanded into a huge UPDATE/SET style output.

My questions:

• Why does LakeBridge transpiler behave differently for scripts of the same pattern?

• Is there any known limitation or specific rule in LakeBridge that causes such variation?

• Is there a way to standardize/optimize the conversion so it doesn’t blow up into thousands of lines?

Thanks in advance for any guidance!

Note: This is just a similar example to illustrate the issue, not my original script.

[deny67gomez]

Hello,

When using the LakeBridge transpiler, it’s common to see inconsistent behavior when converting stored procedures, especially as the complexity of the script increases. Simple scripts usually convert correctly, but medium or complex scripts with multiple LEFT JOINs, column extractions, or nested expressions can trigger a verbose conversion style. In such cases, the transpiler often expands queries into repeated SET … = (SELECT …) statements rather than preserving the original multi-join structure. Even scripts with very similar patterns can behave differently due to minor differences in aliases, join order, or expression placement. This happens because LakeBridge parses SQL into an internal abstract representation and sometimes falls back to row-by-row assignments to ensure correctness, particularly when target dialects have limitations. To reduce this “line blow-up,” it’s recommended to simplify joins and expressions, use consistent aliases, split large procedures into smaller units, and consider post-conversion optimization to merge repetitive statements into structured queries. While the converted code remains functionally correct, these strategies help maintain readability and avoid unnecessarily long outputs.