Drop explicit ROW constructor from SELECTs

[ryannedolan]

Summary

Drop explicit ROW(...) constructor from SELECTs in SQL output.

Details

Flink seems to choke on pipelines like INSERT INTO ... SELECT ROW(HEADER.NAME) FROM FOO. The Flink SQL parser is fine with ROW(...) but only if the expressions inside the constructor do not include a field access .. Some experiments:

• SELECT ROW(HEADER) FROM FOO 👍
• SELECT ROW(HEADER.NAME) FROM FOO 👎
• SELECT (HEADER.NAME) FROM FOO 👍

This seems like a bug to me, but the last case points to a workaround: we can simply drop the explicit ROW, and rely on the parser treating (...) as the same thing.

Testing

This was difficult to test, so I did so manually. The artificially complicated subscription SELECT ROW("quantity") AS V, "product_id" AS KEY FROM INVENTORY."products_on_hand" is rendered as follows:

INSERT INTO `RAWKAFKA`.`products` (`V`, `KEY`) SELECT(`quantity`) AS `V`,
        `product_id` AS `KEY` FROM `INVENTORY`.`products_on_hand

...whereas previously this would have been rendered with a ROW(...) constructor. The Flink parser seems to be happy with the change.