fix(db): explicitly create search functions in public schema#67
Merged
Conversation
PR #66 qualified cross-function calls with public. but the CREATE FUNCTION statements themselves had no schema prefix. On Supabase hosted projects the migration runner's search_path may not default to public, so the functions were created in the wrong schema while the qualified calls pointed at public — where nothing existed. Prefix all CREATE FUNCTION, ALTER TABLE, and CREATE INDEX statements with public. so the migration is fully schema-explicit and independent of the session's search_path. Co-authored-by: Ona <no-reply@ona.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Collaborator
Author
|
✅ UI verification skipped — no UI files changed (only |
Collaborator
Author
|
✅ Post-merge verification passed. Routes tested:
Skipped: None — all routes exist and passed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
PR #66 added
public.to cross-function calls but theCREATE FUNCTIONstatements themselves had no schema prefix. On Supabase hosted projects the migration runner'ssearch_pathmay not default topublic, so the functions were created in the wrong schema while the qualified calls pointed atpublic.extract_text_from_lexical— which didn't exist there.The Deploy Migrations workflow has now failed on 5 consecutive pushes to
main, including the PR #66 merge itself.Changes
1. Schema-qualify all DDL in the search migration
Prefix all statements with
public.:CREATE OR REPLACE FUNCTION public.extract_text_from_lexicalCREATE OR REPLACE FUNCTION public.page_search_vectorCREATE OR REPLACE FUNCTION public.search_pagesALTER TABLE public.pagesCREATE INDEX ... ON public.pagespublic.page_search_vector(title, content)public.extract_text_from_lexical(child)/(content -> 'root')The migration is now fully schema-explicit and independent of the session's
search_path.2. Replace dry-run with staging DB validation
supabase db push --dry-runonly lists pending migrations — it doesn't execute SQL. This is why the original bug passed PR checks but failed on deploy.The PR job now:
SUPABASE_STAGING_PROJECT_ID)supabase db reset --linkedto wipe staging to a clean statesupabase db pushto apply all migrations for realThis catches runtime SQL errors (missing functions, schema resolution, syntax in PL/pgSQL bodies) before merge.
Requires two new repository secrets:
SUPABASE_STAGING_PROJECT_ID— project ref for the staging Supabase instanceSUPABASE_STAGING_DB_PASSWORD— database password for the staging instanceA
concurrencygroup serializes staging access so parallel PRs don't collide.