supabase / supabase-flutter / 35862863159

94%

push

github

fix(postgrest): escape reserved characters in quantified pattern lists (#1869)

## What

The four quantified pattern filters join their patterns with a bare
comma:

```dart
'like(all).{${patterns.join(',')}}'
```

Every other list or array filter in this same builder escapes its
members through `_cleanFilterList`, including `not()` with the very same
operator. So today these two calls disagree:

```dart
.likeAllOf('name', ['a,b'])          // name=like(all).{a,b}
.not('name', 'like(all)', ['a,b'])   // name=not.like(all).{"a,b"}
```

The second one is right. PostgREST does not parse the `{...}` of a
quantified operator itself: `pSingleVal` takes the rest of the value
verbatim and `pgFmtFilter` renders it as `LIKE ALL($1)` with `$1` an
unknown-typed literal, which Postgres then coerces to `text[]`. Postgres
array-literal rules therefore apply in full, and unescaped input breaks
them:

- `['a,b']` becomes the two patterns `a` and `b`. Under `all` nothing
matches, under `any` too much does. No error either way, just wrong
rows.
- `[r'50\%']` loses its backslash to the array parser, so LIKE sees
`50%` and the wildcard the caller escaped fires anyway.
- `['a}b']` closes the literal early and `['a"b']` opens a quote inside
it, so the request fails in Postgres rather than returning wrong rows.
- `['']` collapses to `{}`, an empty array, which `LIKE ALL` treats as
vacuously true for every row.

This is the same bug #1481 fixed for `in.(...)`, in the four places that
were not part of it. The typed builder added in #1857 already gets it
right (`postgrest_filter_operators_test.dart` asserts
`content=like(any).{"a,b",c}`), so this also stops the two surfaces from
disagreeing about the same query.

## How

`_cleanFilterList(patterns)` in place of `patterns.join(',')` at the
four sites. No new helper and no behaviour change for a pattern that
needs no quoting, since `"%supa%"` and `%supa%` are the same array
element.

## Tests

Five in `packages/postgrest/test/filt... (continued)

8 of 8 new or added lines in 1 file covered. (100.0%)

8324 of 9186 relevant lines covered (90.62%)

4.88 hits per line