Skip to main content
Supported Regions:上海

Schema cache issues

The CloudBase PostgreSQL HTTP API is based on PostgREST. PostgREST caches database schema information, so after changing tables, functions, or relationships, the HTTP API may briefly use the old schema.

Common symptoms​

  • A newly added column is missing from HTTP API responses.
  • RPC calls report that a function does not exist.
  • After function parameters change, the HTTP API still validates the old parameters.
  • After adding a foreign key, embedded relation queries are unavailable.

Confirm SQL layer changes​

Check table columns in DMC:

select column_name, data_type
from information_schema.columns
where table_schema = 'public'
  and table_name = 'todos'
order by ordinal_position;

Check functions:

select routine_name, data_type
from information_schema.routines
where routine_schema = 'public';

If the SQL layer does not show the change, the schema or function creation did not succeed.

Handling​

If the SQL layer has changed but the HTTP API has not, wait for schema cache refresh or use the console-provided entry to refresh the API schema when available.

For releases, finish schema and function changes first, then wait for or trigger schema refresh, and finally release frontend or backend code that depends on the new fields.

RPC function notes​

PostgREST is sensitive to function signatures. When changing function parameters, use create or replace function with explicit parameter names and types.

create or replace function public.search_todos(keyword text)
returns setof public.todos as $$
  select *
  from public.todos
  where title ilike '%' || keyword || '%';
$$ LANGUAGE SQL STABLE;

For calls, see Call RPC.

Prevention​

  • Separate schema changes from API releases.
  • Avoid frequent function signature changes in the same release window.
  • Add compatibility logic for new fields used by HTTP API clients.
  • Verify schema refresh in staging before production.