GeezerVison

For DuckDB, whose lists and strings support slices with omitted bounds and a step (docs).

Inside a subscript, : was read as the Snowflake JSON path operator, so slices did not parse as slices:

• A : at the top level of a subscript (col[...], expr[...]), outside any brackets, braces, parentheses or CASE opened in it, separates slice bounds instead of starting a JSON path. JSON paths elsewhere are unchanged: c:a[1], l[(SELECT c:a FROM t)], l[f(c:a)], l[ARRAY[c:a]].
• Behaviour changes inside a subscript: l[:name] / l[:1] are now slices up to name / 1, no longer a JDBC named parameter / numeric bind; Snowflake's l[v:i] is now a slice. Both follow PostgreSQL and DuckDB slice syntax.
• RangeExpression (column subscripts) and ArrayExpression (other subscripts) gain a step and accept missing bounds. A missing stop before a step deparses as -, since l[1::2] would lex as a cast.
• TablesNamesFinderTraversalTest asserted the JsonExpression parse of f()[1:2]; it now asserts the slice bounds.
• checkGrammarAmbiguity: no conflicts. ./gradlew check: 10,121 tests, 0 failures.
• DuckDB's own test suite (test/sql, 70,729 statements): 36 more parse, none less.