feat: tx list function name fuzzy search

[He1DAr]

Implemented fuzzy search for transaction list query using the pg_trgm extension, starting with indexing the contract_call_function_name column. Future plan is to expand the index to cover more columns, improving search flexibility, 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
  ....
);

[github-actions]

Vercel deployment URL: https://stacks-blockchain-hoasndf9j-hirosystems.vercel.app 🚀

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[zone117x]

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.

[He1DAr]

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.

[zone117x]

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".

[zone117x]

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``;

[zone117x]

The code looks good to me. My last concern before merging is around query performance. @He1DAr can you work with devops to get this branch deployed to our dev environment?

[rafaelcr]

LGTM, but I agree that we should deploy this to dev to give it a test before merging

[saralab]

@zone117x @rafaelcr What's the latest on this? We discussed the next steps here a while back, I would like to close all stale PRs ASAP

[zone117x]

In the associated issue I outlined some possible next steps that could be taken to make this feature work #2164 (comment)