"simple" textSearch config not working as expected

[Tsunetsuki]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

With textSearch, I cannot find a way to search for stopwords like and or the. This is expected when using the default english text config since this will filter stopwords, but when using the simple textSearch config the behaviour should be to get search results for any words entered.

To Reproduce

For a given table tbl with a text column col:

const textSearchText = "and";
const { data } = await supabase
  .from(tbl)
  .select()
  .textSearch(col, textSearchText, {
    type: "websearch",
    config: "simple",
  });

Expected behavior

Get rows where col contains the string "and".

Actual behavior

No results.

System information

• OS: [Android (React Native)]
• Version of supabase-js: [2.39.3]
• Version of Node.js: [22.1.0]

Additional context

I would expect the above code to yield the same results as this SQL:

SELECT *
FROM tbl
WHERE to_tsvector('simple', col) @@ to_tsquery('simple', 'and');

[silentworks]

I can't find any documentation around the simple config as this isn't documented in the Supabase Docs nor in the PostgREST docs when I had a look. I don't think textSearch works with stop words at all. You can create an Postgres function like you have above and call it via .rpc for this use case.

[steve-chavez]

Related #402

[silentworks]

@steve-chavez you tagged this same post in your message above.

[laurenceisla]

I would expect the above code to yield the same results as this SQL:

SELECT *
FROM tbl
WHERE to_tsvector('simple', col) @@ to_tsquery('simple', 'and');

Not exactly, textSearch() will convert it to something like:

SELECT *
FROM tbl
WHERE col @@ to_tsquery('simple', 'and');

In this case, PostgreSQL will do an implicit to_tsvector(col) casting. I gave more info here: #402 (comment)

[Hallidayo]

Hi, I've moved this issue over from the supabase repo.

[steve-chavez]

@laurenceisla This and #402 (comment) can already be closed since PostgREST/postgrest#2255 was solved?