chore: libpg-query → sql-parser migration cleanup

[lucassalatiel]

Summary

Swaps libpg-query for sql-parser across the web app and updates related modules. Includes a small libpg-query-compat.ts shim so call sites that still expect the legacy API keep working during the transition.

Changes

• apps/web/package.json — replace libpg-query dependency with sql-parser
• apps/web/lib/libpg-query-compat.ts — new compat shim mapping the old surface to sql-parser
• apps/web/lib/sql-util.ts — switch parser import
• apps/web/components/ide.tsx, executed-sql.tsx, deploy-info-dialog.tsx — update parser usage
• apps/web/app/api/integrations/[id]/details/route.ts, apps/web/app/api/oauth/supabase/callback/route.ts — update parser usage
• package-lock.json — regenerated after dependency swap

Why

libpg-query ships native bindings that are awkward to bundle in Next.js / edge runtimes. sql-parser is pure JS and avoids the native build step while keeping the parsing API we rely on.

Test plan

• pnpm --filter web build succeeds
• SQL parsing in IDE, executed-sql panel, and deploy dialog still highlights correctly
• OAuth + integration details routes parse SQL without runtime errors

[vercel]

@lucassalatiel is attempting to deploy a commit to the Supabase Team on Vercel.

A member of the Team first needs to authorize it.

[gregnr]

@lucassalatiel thanks for the PR! To be honest, I don't think sql-parser will be a great fit for this - it's been unmaintained since 2015 and won't capture all the pg-specific syntax that database.build needs.

@supabase/pg-parser is an alternative WASM-based parser that we've built (after database.build was originally created). We also recently fixed the Next.js/SSR build issues - see the Next.js smoke test example. It also should have mostly the same API interface as libpg-query which makes it an easier drop-in replacement.

Can you try swapping in @supabase/pg-parser instead and see if it solves the Next.js/build issues you were facing?