supabase-create-functions

Guidelines for creating database functions in Supabase, a hosted service built around PostgreSQL.

In plain words
What is it for?
Use them when writing Supabase PostgreSQL functions, especially SQL files that need controlled permissions, a fixed search path, and valid queries.
Why use it?
They reduce security risks and help ensure generated SQL functions follow safer permission and schema practices.

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/chand1012/cursorrules/supabase-create-functions
Clone the repo
git clone --depth 1 https://github.com/chand1012/cursorrules
Per session 785 This file is loaded in full into every session.
When invoked 785 The same file — it is already loaded in full.
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.00785 $0.00785
Opus 5 $0.00392 $0.00392
Sonnet 5 $0.00157 $0.00157
Haiku 4.5 $0.00078 $0.00078

Measured 2d ago 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 2d ago.

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.

frameworks/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.


description: Guidelines for writing Supabase database functions globs: **/*.sql alwaysApply: false

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;
$$;

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. 2d ago 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 chand1012/cursorrules (13 stars, last pushed 9mo ago), licensed MIT. It adds 785 tokens to every session, about $0.0039 per session on Opus 5. 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.