Supabase 调 RPC 报 function 不在 schema cache

问题出现得很突然，日志倒是留得挺全。Supabase 项目里用 pgvector 写了 match_documents(query_embedding vector, match_count int)，前端 supabase-js 2 调 rpc('match_documents', {query_embedding, match_count: 5}) 报 Could not find the function public.match_documents(query_embedding, match_count) in the schema cache。

刚开始盯着「刚建完函数，schema cache 还没重载」，折腾了半个多小时，排掉了。

排查方向其实有限，先把可能性排一排。函数参数名与前端传入的键名不一致，PostgREST 匹配不上。少数情况下是函数建在别的 schema，没有暴露给 PostgREST。

不容易想到的是，参数类型写成 vector(1024)，调用时传的是字符串。

上来先确认函数的真实签名和所属 schema

psql "$SUPABASE_DB_URL" -c "select n.nspname, p.proname, pg_get_function_arguments(p.oid) from pg_proc p join pg_namespace n on n.oid=p.pronamespace where p.proname='match_documents';"

接着按签名在 SQL 里直接调用一次

psql "$SUPABASE_DB_URL" -c "select * from match_documents('[0.1,0.2]'::vector, 5);"

通知 PostgREST 重载 schema

psql "$SUPABASE_DB_URL" -c "notify pgrst, 'reload schema';"

等前面都确认过，再把参数名对齐后用 supabase-js 重试

curl -X POST "$SUPABASE_URL/rest/v1/rpc/match_documents" -H "apikey: $ANON_KEY" -H "Content-Type: application/json" -d '{"query_embedding":"[0.1,0.2]","match_count":5}'

中途换过一次思路，把范围缩到最小的那一层，反而快了。

怎么算真的好了，看的是同一批现象。RPC 返回 200 且结果里包含 id、content 和 similarity 三列，同样的请求在 supabase-js 里也不再报 schema cache。

PostgREST 是按参数名做匹配的，SQL 里叫 match_count、前端写成 limit 就必然找不到，改完函数记得 notify 一次，缓存不刷新会一直报旧错。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。