supabase-create-functions

Rules for writing PostgreSQL database functions in Supabase, a service built around PostgreSQL databases. They cover permissions, object naming, valid SQL, and limiting unwanted data changes.

In plain words
What is it for?
Use them when creating or reviewing Supabase database functions, including functions that read data or support triggers.
Why use it?
They help avoid unsafe access settings, unexpected database object resolution, invalid SQL, and unnecessary side effects.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/squirrelogic/cursor-rules/supabase-create-functions
Clone the repo
git clone --depth 1 https://github.com/squirrelogic/cursor-rules
Per session 0 Nothing until a file matches its globs; then the whole rule loads.
When invoked 785 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 92% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.00785
Opus 5 $0.00000 $0.00392
Sonnet 5 $0.00000 $0.00157
Haiku 4.5 $0.00000 $0.00078

Measured yesterday against content hash 1073597057b5, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

supabase-create-functions scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

92% identical to guidelines-for-writing-supabase-database-functions — 5 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

supabase/supabase-create-functions.mdc · 137 lines

How it starts

The opening of the file, as written. The whole thing — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Database: Create functions

You're a Supabase Postgres expert in writing database functions. Generate high-quality PostgreSQL functions that adhere to the following best practices:

General Guidelines

  1. Default to SECURITY INVOKER:

    • Functions should run with the permissions of the user invoking the function, ensuring safer access control.
    • Use SECURITY DEFINER only when explicitly required and explain the rationale.
  2. Set the search_path Configuration Parameter:

    • Always set search_path to an empty string (set search_path = '';).
    • This avoids unexpected behavior and security risks caused by resolving object references in untrusted or unintended schemas.
    • Use fully qualified names (e.g., schema_name.table_name) for all database objects referenced within the function.
  3. Adhere to SQL Standards and Validation:

    • Ensure all queries within the function are valid PostgreSQL SQL queries and compatible with the specified context (ie. Supabase).

Best Practices

  1. Minimize Side Effects:

    • Prefer functions that return results over those that modify data unless they serve a specific purpose (e.g., triggers).
  2. Use Explicit Typing:

    • Clearly specify input and output types, avoiding ambiguous or loosely typed parameters.
  3. Default to Immutable or Stable Functions:

    • Where possible, declare functions as IMMUTABLE or STABLE to allow better optimization by PostgreSQL. Use VOLATILE only if the function modifies data or has side effects.
  4. Triggers (if Applicable):

    • If the function is used as a trigger, include a valid CREATE TRIGGER statement that attaches the function to the desired table and event (e.g., BEFORE INSERT).

Example Templates

Simple Function with SECURITY INVOKER

create or replace function my_schema.hello_world()
returns text
language plpgsql
security invoker
set search_path = ''
as $$
begin
  return 'hello world';
end;
$$;

Function with Parameters and Fully Qualified Object Names

Read the full file on GitHub · 137 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 137 lines · 785 tokens per session scan A 1073597057b5

Subscribe to this mod's changes

supabase-create-functions is a cursor rule published in the GitHub repository squirrelogic/cursor-rules (20 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 785 tokens. A static security scan graded it A with 0 findings. It is 92% identical to guidelines-for-writing-supabase-database-functions, differing in 5 lines, and is treated as a copy.