Skip to content

fix(postgrest): coerce non-string values in array filters - #1530

Merged
o-santi merged 1 commit into
supabase:mainfrom
gottostartsomewhere:fix/postgrest-array-filter-non-string
Jul 9, 2026
Merged

o-santi merged 1 commit into
supabase:mainfrom
gottostartsomewhere:fix/postgrest-array-filter-non-string

Conversation

@gottostartsomewhere

Copy link
Copy Markdown
Contributor

What

Fixes #1529.

The array/range filter methods cs, cd, contains, contained_by, and ov (and overlaps, which delegates to ov) passed values directly to ",".join(...), which raises TypeError on non-string iterables like integer arrays — even though the signatures accept Iterable[Any]. in_ already avoids this by mapping through sanitize_param.

builder.contains("ids", [1, 2, 3])
# TypeError: sequence item 0: expected str instance, int found

Integer array columns (int[]) are common in Postgres, so this is easy to hit.

Change

Coerce each element with str() before joining in the five affected methods, so .contains("ids", [1, 2, 3]) builds {1,2,3}. This mirrors what in_ already does and leaves existing string behaviour unchanged (verified against the existing tests, including ones with reserved characters like overlaps("x", ["is:closed", "severity:high"])).

The change is in the shared base_request_builder.py, so it fixes both sync and async builders.

Tests

Added test_{contains,cs,cd,contained_by,overlaps}_non_string_items to both the async and sync filter-builder test suites. They fail on main (TypeError) and pass with the fix. Full filter test suite: 84 passed.

cs, cd, contains, contained_by and ov (and overlaps, which delegates to
ov) passed values straight to ",".join(...), raising TypeError on
non-string iterables such as integer arrays — despite their signatures
accepting Iterable[Any]. in_ already handles this via sanitize_param.

Coerce each element with str() so e.g. .contains("ids", [1, 2, 3])
produces {1,2,3}. Existing string behaviour is unchanged.

Fixes supabase#1529
@gottostartsomewhere
gottostartsomewhere requested review from a team and o-santi as code owners July 8, 2026 11:46
@o-santi

o-santi commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

I'll accept this as a patch up but I think the proper solution would be to remove the Any from postgrest's argument everywhere, and be more strict on what types the user can/should provide.

@o-santi o-santi closed this Jul 9, 2026
@o-santi o-santi reopened this Jul 9, 2026
@o-santi
o-santi merged commit 3433b0d into supabase:main Jul 9, 2026
39 checks passed
gottostartsomewhere added a commit to gottostartsomewhere/supabase-py that referenced this pull request Jul 9, 2026
Address review on supabase#1530: instead of only coercing values at runtime,
remove Any from the filter argument annotations. Add a FilterValue alias
(str | int | float | bool) and type the array/collection filters (in_, cs,
cd, contains, contained_by, ov, overlaps) with it, and type the JSON-object
branch as Dict[str, JSON]. Runtime str-coercion is kept so integer arrays
still work. mypy clean; existing tests pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

postgrest: array filters (cs/cd/contains/contained_by/ov) raise TypeError on non-string values

2 participants