Should this also be paired with something like a search_field_name, which current supports contract_call_function_name? Seems like there will be use cases were a search will not be interested in every single supported field.

The idea is to have the search_term as a broad search filter that looks into multiple fields. My plan so far is to incrementally add more fields to the same index and test performance, e.g.:

CREATE INDEX idx_search_term_trgm
ON public.txs
USING gin (
 contract_call_function_name gin_trgm_ops,
 contract_name gin_trgm_ops
 memo gin_trgm_ops
 ....
);

Open to suggestions ofc.

That seems fine to me. In the future we could always add another query param that lets users specify a given field(s) to search. And for now it can default to "all".

Can this be inlined to avoid another round-trip query to postgres? E.g. something like

const searchTermFilterSql = searchTerm
 ? sql`
 AND (
 CASE
 WHEN EXISTS (
 SELECT 1
 FROM pg_extension
 WHERE extname = 'pg_trgm'
 )
 THEN similarity(contract_call_function_name, ${searchTerm}) > ${TRGM_SIMILARITY_THRESHOLD}
 ELSE contract_call_function_name ILIKE '%' || ${searchTerm} || '%'
 END
 )
 `
 : sql``;