How a Bash Quoting Artifact Broke Our Production PostgreSQL Deploy

The Mystery Error

Our production Supabase migration deploy suddenly started failing with SQLSTATE 42601:

ERROR: syntax error at or near "'"" (SQLSTATE 42601)
At statement: 0
-- AI University content: Hailuo AI (MiniMax)

The SQL file looked perfectly fine in the editor. After investigation, the culprit turned out to be a bash shell quoting artifact ('"'"') that had leaked directly into a SQL migration file.

What is '"'"'?

In bash, you can't use a single quote ' inside a single-quoted string. The workaround is to close the string, insert the character in double-quotes, then reopen:

# Three-part construction:
'...'   # single-quoted string
"'"     # single quote in double-quotes
'...'   # resume single-quoted string

# Commonly seen in curl -d:
curl -d '"'"'{"key":"value"}'"'"'
# Expands to: '{"key":"value"}'

This '"'"' pattern is a valid bash escaping technique — but it's meaningless (and dangerous) in SQL.

What Went Wrong

We were inserting API documentation with curl examples directly into a SQL migration file:

-- Problematic SQL (shell quoting artifact leaked in)
INSERT INTO ai_university_content (...) VALUES
(
  'hailuo', 'api', 'API Guide',
  E'...curl examples...\n  -d '"'"'{\n    "model": "video-01"\n  }'"'"'\n...',
  ...
)

The bash curl example was copy-pasted into SQL string content without being escaped.

Here's what PostgreSQL sees when it hits '"'"':

1. ' → string start
2. " → literal " character
3. ' → string end (parser thinks the string is closed here)
4. "' → syntax error 42601

The Fix

Option 1: SQL escape with '' (what we used)

In PostgreSQL E-string notation (E'...'), escape single quotes by doubling them:

-- Fixed
E'...-d ''{\\n    "model": "video-01"\\n  }''\\n...'

Python batch fix across migration files:

content = open('migration.sql', 'r', encoding='utf-8').read()
content = content.replace("'\"'\"'", "''")
open('migration.sql', 'w', encoding='utf-8').write(content)

Option 2: Dollar-quoting (cleaner for long content)

-- No escaping needed inside $$...$$
$$
-d '{"model": "video-01"}'
$$

For long content with many single quotes, dollar-quoting is much more readable.

Prevention

1. CI Gate — catch it before it reaches production

We added this step to our ci.yml:

- name: Check SQL migration shell quoting artifacts
  run: |
    python3 -c "
    import os, sys
    found = []
    for f in os.listdir('supabase/migrations'):
        if f.endswith('.sql'):
            path = os.path.join('supabase/migrations', f)
            content = open(path, errors='replace').read()
            if \"'\\\"'\\\"'\" in content:
                found.append(path)
    if found:
        print('FOUND: ' + ', '.join(found))
        sys.exit(1)
    else:
        print(f'OK: {len(found)} issues in migrations')
    "
  continue-on-error: false

This blocks the deploy before the artifact reaches Supabase.

2. Use dollar-quoting for shell code samples

-- Safe: no quoting issues
INSERT INTO content (body) VALUES (
  $$
  curl -X POST https://api.example.com \
    -H "Content-Type: application/json" \
    -d '{"model": "video-01"}'
  $$
);

3. Also fixed: GitHub Actions workflow quoting

A related issue: ${{ steps.outputs.title }} injected directly into a bash string breaks when the title contains ":

# Dangerous — breaks if title has double-quotes
run: |
  TITLE="${{ steps.meta.outputs.title }}"

# Safe — pass through env: block
env:
  ARTICLE_TITLE: ${{ steps.meta.outputs.title }}
run: |
  TITLE="$ARTICLE_TITLE"

GitHub Actions substitutes ${{ }} expressions before the shell runs — so any " in the value terminates the outer string.

Summary

Key takeaway: When embedding shell code samples in SQL migration files, always use dollar-quoting ($$) or sanitize '"'"' → '' before committing. Add a CI gate to catch it automatically.

Building in public: https://my-web-app-b67f4.web.app/

PostgreSQL #Supabase #bash #buildinpublic #GitHubActions