Expression Node: Join doesnt respect indentation

Expression Nodes Join function cannot differentiate between indentation for its function and the overall input box.
tabs are taken absolute in each line instead of relative to previous lines

node expression input

join(
    "",
    "ALTER TABLE abc
    ADD ...;"
)

output

ALTER TABLE abc
    ADD ...;

expected output

ALTER TABLE abc
ADD ...;

obviously gets worse with more nesting (if the join node is nested or the statements created have more nesting)

currently, you have to create write

join(
    "",
    "ALTER TABLE abc
ADD ...;"
)

to achieve

ALTER TABLE abc
ADD ...;

potentially affects other string functions like string(), too

@fe145f9fb2a1f6b This is expected behavior. join() does not infer indentation from formatting. Any leading spaces inside a string literal are preserved. If you want structured multiline output, use "\n" as a delimiter and split the lines into separate arguments.

If the desired output is as below:

I would recommend using something like

join("\n","ALTER TABLE abc","ADD ...;")

hi @k10shetty1 firstly, i would use \r\n instead of \n
secondly, that approach would fail horribly if you write generic code:

join(
    "\r\n",
    "ALTER TABLE ", $$(SQL.identifier.open)$$, $(table-name), $$(SQL.identifier.close)$$,
    "ADD ...;"
)

would end up looking like

ALTER TABLE
[
tablename
]
ADD ...;

@fe145f9fb2a1f6b This behavior is actually by design. The join() function does not interpret indentation or code structure. It inserts the specified delimiter between every argument provided.

In your example, the newline delimiter is being applied even between identifier tokens (like [, table name, ]), which is why the table name ends up split across multiple lines. The function isn’t aware that those three parts belong to the same line of logic; it just sees three separate arguments to join.

If you want multi-line SQL where some parts stay on the same line, the best approach is to build the complete lines first and then join those lines together.

For example, you can nest join() calls:

join("\n",
join("","ALTER TABLE ", "[", "table", "]",),
join("","ADD ", "[", "table", "];"))

Hope that helps!

1 Like

I am aware of how to deal with it.

this report was essentially just to make you folks aware that your current solution ignores indentation levels from the function itself in the editor.

afaik, most programming languages ignore newlines within quotation marks and require explicit \r\n or \t instead for structured output.

its just annoying that you either create ugly code or ugly output.

@fe145f9fb2a1f6b Thanks for the clarification. I see your point regarding the trade-off between editor readability and clean output.

I have moved this thread to the Feedback & Ideas category so it can be tracked as a feature request for better multi-line string handling.

Hi @fe145f9fb2a1f6b, thanks for the report.

In the Expression language, string literals preserve whitespace exactly as written — including indentation inside multi-line strings. So the spaces you add for readability in the editor become part of the output. That’s intentional today (similar to Python/JS), but we agree it can be painful for cases like building SQL where you want nicely indented expressions and clean output.

Some languages offer indentation-normalizing multi-line strings (e.g. Java Text Blocks). We’ll explore a similar option for Expressions; I’ve created ticket AP-25602 to track this.

You can still control line breaks explicitly via \n / \r\n or line continuations, but that mainly helps with placing newlines — it doesn’t solve the indentation issue in generic code:
KNIME Expressions Guide | KNIME Documentation.

3 Likes