[cathleeny]

Description

BUG FIX: Since 4.0.4 (#559), inline parameters (use_inline_params=True) render every Python sequence as an ARRAY(...) literal. The WHERE x IN %(ids)s pattern documented in docs/parameters.md therefore renders as x IN ARRAY(1,2,3), which Spark rejects with PARSE_SYNTAX_ERROR. That blocks users moving from 3.x.

Change: A sequence at a marker that directly follows IN or NOT IN renders as a parenthesised list, (1,2,3), again. Everywhere else it stays an ARRAY(...) literal, including IN (%(p)s) where the caller wrote the parentheses, so the inline writes to ARRAY columns added in #559 keep working. Inside the list, a tuple renders as a row and a list as an ARRAY(...) literal, so a multi-column (a, b) IN %(pairs)s with [(1, 2), (3, 4)] renders as (a, b) IN ((1,2),(3,4)), as on 3.x.

Scope:

• Rendering happens in Cursor._prepare_inline_parameters before backend dispatch, so the fix covers the Thrift, SEA and kernel backends.
• When no parameter is a sequence, rendering skips the extra pass and runs the same code as main.
• Spark doesn't widen types inside a row, so each value must have its column's type: the literal 1 is an INT and doesn't match a BIGINT column. docs/parameters.md says so.
• Unchanged:
  • An empty sequence renders as IN (), which Spark rejects with INVALID_SQL_SYNTAX.EMPTY_IN_PREDICATE, the same as on 3.x.
  • A marker separated from IN by a comment keeps the ARRAY rendering.
• An earlier community PR (Fix inline list parameter rendering for IN clauses #773) rendered every top-level sequence as (...). That would break the inline ARRAY inserts covered by test_primitive_single[INLINE-ARRAYS] and test_inline_recursive_complex_type, so this change only targets the IN position.

How is this tested?

• Unit:

  • The full unit suite passes (-m "not realkernel"), and black --check src and mypy src are clean.

• E2E:

  Case	main	This PR
  id IN %(ids)s with [1, 3]	PARSE_SYNTAX_ERROR	rows 1, 3
  id NOT IN %(ids)s with (1, 3)	PARSE_SYNTAX_ERROR	rows 0, 2, 4
  single element [2]	PARSE_SYNTAX_ERROR	row 2
  strings containing ' and \	PARSE_SYNTAX_ERROR	both match
  same name after IN and in array_contains	PARSE_SYNTAX_ERROR	rows 1, 3
  IN %(ids)s ... LIMIT %(n)d	PARSE_SYNTAX_ERROR	rows 1, 3
  PIVOT (... FOR k IN %(ks)s)	PARSE_SYNTAX_ERROR	a=1, b=2
  position('b' IN %(s)s) with ["abc"]	DATATYPE_MISMATCH	2
  nested arrays [[1, 2], [3]]	PARSE_SYNTAX_ERROR	rows [1,2], [3]
  a date and NULL	PARSE_SYNTAX_ERROR	row 2024-01-02
  Decimal("1.50")	PARSE_SYNTAX_ERROR	row 1.50
  empty list	PARSE_SYNTAX_ERROR	EMPTY_IN_PREDICATE, as on 3.x
  (id, tag) IN %(pairs)s with [(1, "a"), (2, "x"), (3, "c")]	PARSE_SYNTAX_ERROR	rows 1, 3
  (a, b) NOT IN %s with ((1, 2), (3, 4))	PARSE_SYNTAX_ERROR	row (5, 6)
  Row objects from fetchall()	PARSE_SYNTAX_ERROR	row (3, 4)
  rows of INT literals against BIGINT columns	PARSE_SYNTAX_ERROR	DATATYPE_MISMATCH (Spark doesn't widen row types)

  The unchanged renderings, array_contains(%(p)s, 2) and arr IN (%(p)s), still return the expected results.

Related Tickets & Documents

Fixes #629

[peco-review-bot]

✅ No issues identified by the review bot.

[peco-review-bot]

Verdict: 1 Low

Looks good overall, with one low-severity edge case in IN detection. The probe-based per-marker approach is correct for named, positional, %% and %d markers, and it keeps the code path main uses when no parameter is a sequence. Nit (not posted inline): the new render_inline / _sequence_markers_following_in signatures leave parameters/escaped untyped, unlike the typed helpers next to them.

[peco-review-bot]

Verdict: 1 Nit

Looks good. I found no correctness issues. The probe-based detection uses the same %-formatting as the real substitution, so marker numbering lines up for named, positional and %% cases. Errors still surface the same way as before, and queries without a sequence parameter render exactly as they do on main. The only note is a nit: a CHANGELOG entry is missing.

Other findings

• ⚪ Nit — Consider adding an entry under # Unreleased in CHANGELOG.md. This is a user-visible fix for a 4.0.4 regression (#629) that blocks users migrating from 3.x.

[peco-review-bot]

Verdict: 1 Low

The change looks correct and is well tested, with 1 low concern. The probe-based detection of markers after IN keeps %% and positional numbering consistent and keeps value text from affecting detection. It falls back to the main behaviour whenever no parameter is a sequence or set, and its limits as a text heuristic (string literals, block comments) are documented in the code and in docs/parameters.md.

[peco-review-bot]

Verdict: 2 Low

Looks good: two low findings. The per-marker probe design is careful: the probe pass and the real pass use the same %-formatting, string values can't affect IN detection, and errors still match escape_args. One docstring line breaks the 100-char limit, and one test can't fail even if the nonce check it targets is removed.

[peco-review-bot]

Verdict: 1 Low

Looks good: one low test-coverage gap. The probe-based per-marker detection keeps %%, positional/named numbering and the error parity with escape_args intact, and sets and bytes are handled carefully, with thorough tests.