fix(exasol): treat LISTAGG second argument as the separator CLAUDE

[gaoflow]

Summary

Exasol mis-parses the second argument of LISTAGG. FUNCTION_PARSERS routes both GROUP_CONCAT and LISTAGG through the MySQL-style _parse_group_concat, so LISTAGG(expr, sep) folds the separator into the value with a CONCAT instead of treating it as the separator:

>>> import sqlglot
>>> sqlglot.parse_one("SELECT LISTAGG(x, ',') WITHIN GROUP (ORDER BY y) FROM t", read="exasol")
# GroupConcat(this=Concat(x, ','), separator=None)   <-- wrong

Every sibling dialect parses the identical SQL correctly (this=x, separator=','):

dialect	LISTAGG parser
Oracle	_parse_string_agg
Snowflake	_parse_string_agg
Trino	_parse_string_agg
DuckDB	_parse_string_agg
Exasol	_parse_group_concat ← bug

The wrong AST is also non-idempotent: re-parsing the emitted SQL nests another CONCAT.

Fix

Route Exasol's LISTAGG through _parse_string_agg (which maps the second argument to the separator), matching the sibling dialects. GROUP_CONCAT stays on _parse_group_concat, since Exasol's GROUP_CONCAT genuinely uses the MySQL SEPARATOR keyword.

After the fix, Exasol's LISTAGG AST is identical to Oracle/Snowflake/Trino/DuckDB and round-trips cleanly.

Verification

• Reproduced on main (945d1e9d): Exasol LISTAGG(x, ',') parses to a CONCAT-folded AST that differs from all four sibling dialects.
• Added a round-trip identity test and a cross-dialect read test in test_stringFunctions; both fail before the fix and pass after.
• Confirmed the fixed Exasol AST is == to the Oracle/Snowflake/Trino/DuckDB ASTs for the same SQL, and that GROUP_CONCAT parsing is unchanged.
• Full test suite: 1126 passed, 18227 subtests, no regressions. ruff clean.

---

This pull request was prepared with the assistance of AI, under my direction and review.

[geooo109]

Based on the exasol grammar with this fix we can support the listagg_overflow syntax.

In order to achieve this generation, we should change the groupconcat_sql in sqlglot/generators/exasol.py -> TRANSFORMS dict to this:

exp.GroupConcat: lambda self, e: groupconcat_sql(self, e, on_overflow=True),

After this, we should add validate_identity tests for this syntax:

self.validate_identity(
    "LISTAGG(x, ',' ON OVERFLOW ERROR) WITHIN GROUP (ORDER BY y)"
)
self.validate_identity(
    "LISTAGG(x, ',' ON OVERFLOW TRUNCATE '...' WITH COUNT) WITHIN GROUP (ORDER BY y)"
)
self.validate_identity(
    "LISTAGG(x, ',' ON OVERFLOW TRUNCATE '...' WITHOUT COUNT) WITHIN GROUP (ORDER BY y)"
)

Also there is a bug with the default delimiter but I will fix it in a following PR.

[gaoflow]

Thanks @geooo109 — done. I added on_overflow=True to the Exasol GroupConcat transform so the ON OVERFLOW clause survives generation, and added the three validate_identity cases you suggested:

LISTAGG(x, ',' ON OVERFLOW ERROR) WITHIN GROUP (ORDER BY y)
LISTAGG(x, ',' ON OVERFLOW TRUNCATE '...' WITH COUNT) WITHIN GROUP (ORDER BY y)
LISTAGG(x, ',' ON OVERFLOW TRUNCATE '...' WITHOUT COUNT) WITHIN GROUP (ORDER BY y)

All three round-trip now, and the existing Exasol suite (20 tests / 582 subtests) plus the Oracle/Snowflake/Presto/Trino/DuckDB dialect suites stay green. I left the default-delimiter bug alone since you mentioned you'd handle it in a follow-up.