How to fix 38001: containing_sql_not_permitted in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 12, 2025· 100 views

PostgreSQL raises error 38001 when SQL statements are attempted in contexts where they are explicitly prohibited, typically for security reasons. This occurs in security-definer functions, certain procedural language handlers, or when attempting to execute SQL in contexts that could bypass security controls.

Quick fix

Fixes 38001

SELECT proname, prosecdef, prokind, prolang, prosrc 
FROM pg_proc 
WHERE proname = 'your_function_name';
  1. Identify the context where SQL is being attempted
  2. Review function security attributes and permissions
  3. Modify function design to comply with security restrictions
  4. Test the modified function and verify security compliance
postgresql — error
SELECT proname, prosecdef, prokind, prolang, prosrc 
FROM pg_proc 
WHERE proname = 'your_function_name';
38001: containing_sql_not_permitted

What this error means

SQLSTATE 38001 belongs to class 38 (containing SQL not permitted) in PostgreSQL's error catalog. This error occurs when SQL statements are attempted in contexts where they are explicitly prohibited for security reasons. PostgreSQL enforces these restrictions to prevent security vulnerabilities, particularly in security-definer functions, certain procedural language handlers, or contexts where SQL execution could bypass intended security controls. The server validates that SQL operations are only performed in permitted contexts to maintain database security integrity.

Typical symptoms

  • Attempting to execute SQL statements within a security-definer function fails with 'ERROR: 38001: containing_sql_not_permitted'.
  • Procedural language handlers or extensions that attempt SQL operations in prohibited contexts trigger this error.
  • Client applications receive SQLSTATE 38001 when trying to execute SQL in contexts where it's explicitly disallowed.
  • The error occurs immediately when the prohibited SQL statement is attempted, preventing any further execution.
  • Database logs show the specific context and attempted SQL that triggered the security violation.

Common causes

  1. Creating or calling a SECURITY DEFINER function that attempts to execute SQL statements in a prohibited context.
  2. Using procedural language handlers (like PL/pgSQL, PL/Python) that attempt SQL operations where they're not permitted.
  3. Attempting to execute dynamic SQL in contexts where it could bypass security controls or privilege escalation checks.
  4. Extensions or custom functions that violate PostgreSQL's security model by executing SQL in restricted execution contexts.
  5. Misconfigured or improperly designed database functions that mix security contexts in ways PostgreSQL prohibits.

How to fix "38001: containing_sql_not_permitted"

1Identify the context where SQL is being attempted

Examine the PostgreSQL error logs and stack trace to identify exactly which function, extension, or procedural handler is attempting the prohibited SQL. The error message typically includes the function name and context. You can also query pg_stat_activity to see recent statements and check pg_proc for function definitions that might be causing the issue.

2Review function security attributes and permissions

Check the security attributes of the function causing the error. Use:

sql
SELECT proname, prosecdef, prokind, prolang, prosrc 
FROM pg_proc 
WHERE proname = 'your_function_name';

Look for SECURITY DEFINER functions that might be attempting SQL in prohibited contexts. Also check function permissions with \df+ function_name in psql. Ensure functions have appropriate security contexts and aren't mixing security models in ways PostgreSQL prohibits.

3Modify function design to comply with security restrictions

Restructure the function to avoid executing SQL in prohibited contexts. Options include:
- Change from SECURITY DEFINER to SECURITY INVOKER if appropriate
- Move SQL operations to permitted contexts or wrapper functions
- Use different procedural languages that don't trigger the restriction
- Implement the logic differently to avoid the security violation

Example of changing security context:

sql
CREATE OR REPLACE FUNCTION my_function() 
RETURNS void 
SECURITY INVOKER -- Changed from SECURITY DEFINER
LANGUAGE plpgsql 
AS $$
BEGIN
  -- SQL operations here
END;
$$;
4Test the modified function and verify security compliance

After modifying the function, test it thoroughly to ensure it works without triggering error 38001. Verify that:
1. The function executes successfully in its intended context
2. No security violations occur
3. The function's behavior matches requirements
4. All SQL operations are now in permitted contexts

Use transaction blocks for safe testing:

sql
BEGIN;
SELECT my_function();
-- Check for errors
ROLLBACK; -- Or COMMIT if successful
5Review and update related functions and extensions

Check for similar patterns in other functions, extensions, or procedural code. Use:

sql
SELECT proname, prosecdef 
FROM pg_proc 
WHERE prosecdef = true 
  AND prolang IN (SELECT oid FROM pg_language WHERE lanname IN ('plpgsql', 'plpythonu', etc.));

Update any functions with similar security context issues. Also review extension documentation for any known restrictions on SQL execution in certain contexts.

Advanced notes

Error 38001 is part of PostgreSQL's comprehensive security model that prevents privilege escalation and security bypasses. SECURITY DEFINER functions run with the privileges of the function owner, which can create security risks if they execute arbitrary SQL. PostgreSQL restricts SQL execution in certain contexts to maintain security boundaries. Understanding PostgreSQL's security model, including function security attributes, execution contexts, and privilege management, is essential for avoiding this error while maintaining database security.

Frequently asked questions

What does "38001" mean?
SQLSTATE 38001 belongs to class 38 (containing SQL not permitted) in PostgreSQL's error catalog. This error occurs when SQL statements are attempted in contexts where they are explicitly prohibited for security reasons. PostgreSQL enforces these restrictions to prevent security vulnerabilities, particularly in security-definer functions, certain procedural language handlers, or contexts where SQL execution could bypass intended security controls.
How do I fix "38001"?
PostgreSQL raises error 38001 when SQL statements are attempted in contexts where they are explicitly prohibited, typically for security reasons. This occurs in security-definer functions, certain procedural language handlers, or when attempting to execute SQL in contexts that could bypass security controls.
What causes "38001"?
Creating or calling a SECURITY DEFINER function that attempts to execute SQL statements in a prohibited context. Using procedural language handlers (like PL/pgSQL, PL/Python) that attempt SQL operations where they're not permitted. Attempting to execute dynamic SQL in contexts where it could bypass security controls or privilege escalation checks.
Is the "38001" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading