AI & Agent Dev Bug Sandbox Back to Radar

Pg-Meta Functions Read-Path Schemas Reject Procedures With Null Return_type

The pg-meta functions API creates procedures with a null return_type, but its row schema expects a non-null string, causing ZodError on functions.list() and functions.retrieve() when procedures are present.

mediumConfidence 90%Supabase Pg-Meta

Origin Analysis

The row schema for function rows declares return_type as z.string(), while PostgreSQL procedures return null for return_type (return_type_id 2278 / void). This mismatch causes Zod parsing to fail for any procedure row.

1. In packages/pg-meta test environment, execute pgMeta.functions.create({ type: 'procedure', name: 'p1', schema: 'public', definition: 'BEGIN NULL; END', language: 'plpgsql' }). 2. Call pgMeta.functions.list() and parse the result with zod.parse. 3. Observe ZodError: invalid_type, expected string, received null at path [17, 'return_type']. 4. Similarly, pgMeta.functions.retrieve({ name: 'p1', schema: 'public', args: [] }) and parse result fails.

Fixing Code Block

// In packages/pg-meta/src/functions.ts, locate the row schema (pgFunctionRowZod)
// and change the return_type field from:
return_type: z.string(),
// to:
return_type: z.string().nullable(),

Making return_type nullable in the zod schema allows rows for procedures (which have null return_type) to pass validation while still requiring a string for functions that return a type.

Edge Case Audit

Changing the schema to nullable may require updating TypeScript types and any downstream consumers that assume return_type is always a string. Ensure tests cover both functions and procedures, and consider updating any UI or tooling that relies on non-null return_type. Rollback by reverting to z.string() if broader type changes are undesirable.