CLI workflow

Query PostgreSQL Safely with a CLI

Use psql non-interactively with a read-only role, bounded queries, and machine-readable output.

DatabasesRead only

Prepare tools, authentication, and evidence first

Install the recommended tools, confirm minimum permissions, and keep compatibility separate from real execution records.

psqlverified
Query PostgreSQL non-interactively with explicit credentials, output, transactions, and write boundaries.

Recommended install

$ shell
brew install libpq
Authentication
connection URI, password file, service file, peer authentication
Tested agents
No agent-specific execution record
Evidence status
verified · Documentation checked 2026-07-10
Independent CLI execution
18.1 · 2 checks
jqverified
Parse, filter, validate, and transform JSON locally with deterministic output.

Recommended install

$ shell
brew install jq
Authentication
No authentication for the base operation
Tested agents
No agent-specific execution record
Evidence status
verified · Documentation checked 2026-07-10
Independent CLI execution
jq-1.7.1-apple · 4 checks

Copy or download this workflow Skill

The Skill includes input and output contracts, recommended tools, approval points, rollback, and evidence boundaries. Review it against the active environment before saving.

query-postgres-SKILL.md
---
name: query-postgres-workflow
description: "Use psql non-interactively with a read-only role, bounded queries, and machine-readable output."
---

# Query PostgreSQL

## Intended outcome

Answer a database question without exposing credentials or modifying data.

## Evidence boundary

- Tool status distinguishes `docs-verified` material from independent execution; the two are not interchangeable.
- The current registry does not attribute a tool execution to a particular agent, so compatible agents cannot be called tested agents.
- Reconfirm the target account, environment, version, and official documentation before execution.
- Never auto-execute an R2, R3, or confirmation-marked step; obtain explicit approval immediately before it runs.

## Recommended tools, installation, and authentication

- **PostgreSQL psql** (evidence: `verified`, docs checked: `2026-07-10`, independently tested version 18.1 recorded)
  - Install: `brew install libpq`
  - Authentication: connection URI, password file, service file, peer authentication
  - Minimum permissions: Use a read-only database role, TLS, and a database/schema search path limited to the task.
- **jq** (evidence: `verified`, docs checked: `2026-07-10`, independently tested version jq-1.7.1-apple recorded)
  - Install: `brew install jq`
  - Authentication: not required for the base operation
  - Minimum permissions: No service credential is required; restrict filesystem and network access to the task.

## Input contract

- Connection identifier from the environment
- read-only database role
- question and row limit
- expected columns

## Output contract

- Bounded query result
- query text
- timing or error details
- interpretation with limitations

## Safe workflow

1. **Confirm the target safely** — Use environment-backed connection settings and print database identity without printing a password.
   - Input: Connection environment and read-only role
   - Output: Confirmed host, database, and user
   - Risk: `read-only`
   - Command: `psql -X -v ON_ERROR_STOP=1 -c "select current_database(), current_user"`
2. **Run a bounded read** — Wrap SELECT work in a read-only transaction and request a parseable format.
   - Input: Reviewed SELECT query
   - Output: CSV or unaligned rows
   - Risk: `read-only`
   - Command: `psql -X --csv -v ON_ERROR_STOP=1 -c "begin read only; select * from example limit 100; commit;"`
3. **Report query and limits** — Return the query, row count, output shape, and any assumptions without echoing credentials.
   - Input: Query result and error stream
   - Output: Database answer with provenance
   - Risk: `read-only`

## Ask before proceeding

- Any INSERT, UPDATE, DELETE, DDL, migration, or function call with side effects
- Connecting with an owner or superuser role
- Exporting sensitive or high-volume rows

## Rollback

- Use a read-only transaction so the default path has nothing to roll back
- For approved writes, wrap changes in a transaction and verify before commit
- Restore from a tested backup for changes that cannot be transactionally reversed

## Official sources

- [PostgreSQL psql documentation](https://www.postgresql.org/docs/current/app-psql.html) — Official psql options, variables, output formats, and execution behavior.

Outcome, inputs, and outputs

Define the result and evidence before the agent selects a command.

Goal

Answer a database question without exposing credentials or modifying data.

Required inputs

  • Connection identifier from the environment
  • read-only database role
  • question and row limit
  • expected columns

Expected outputs

  • Bounded query result
  • query text
  • timing or error details
  • interpretation with limitations

Query PostgreSQL Safely with a CLI: safe workflow

Run each step inside its stated boundary and verify the output before continuing.

Step 1Read only

Confirm the target safely

Use environment-backed connection settings and print database identity without printing a password.
Input
Connection environment and read-only role
Output
Confirmed host, database, and user
$ Confirm the target safely
psql -X -v ON_ERROR_STOP=1 -c "select current_database(), current_user"
Step 2Read only

Run a bounded read

Wrap SELECT work in a read-only transaction and request a parseable format.
Input
Reviewed SELECT query
Output
CSV or unaligned rows
$ Run a bounded read
psql -X --csv -v ON_ERROR_STOP=1 -c "begin read only; select * from example limit 100; commit;"
Step 3Read only

Report query and limits

Return the query, row count, output shape, and any assumptions without echoing credentials.
Input
Query result and error stream
Output
Database answer with provenance

Approval points and rollback

Pause at the listed decision points and keep recovery instructions beside the action.

Ask before these actions

  • Any INSERT, UPDATE, DELETE, DDL, migration, or function call with side effects
  • Connecting with an owner or superuser role
  • Exporting sensitive or high-volume rows

Recovery plan

  • Use a read-only transaction so the default path has nothing to roll back
  • For approved writes, wrap changes in a transaction and verify before commit
  • Restore from a tested backup for changes that cannot be transactionally reversed

CLI, MCP, or API?

Choose the interface by execution location, identity, output contract, and permission boundary.

CLI

Excellent for transparent, bounded SQL and CI diagnostics when credentials are already managed.

MCP

Useful when the agent should see only approved query tools or schemas.

API

Prefer when application authorization, row-level policies, and stable response contracts must be enforced.

Recommended approach

Use psql with a read-only role for direct diagnostics; choose an API for user-facing data access.

Official evidence and references

Use these primary or upstream sources to verify current command behavior before acting.

PostgreSQL psql documentation

Official psql options, variables, output formats, and execution behavior.

Questions before you run it

Is SELECT always safe?

Not necessarily; functions can have side effects and unbounded reads can be expensive. Use a read-only role, limits, and timeouts.

Where should the password go?

Use an established secret mechanism such as the process environment or a protected password file, never a pasted command or report.

Related tools and guides

Browse sibling guides and choose the next page that best matches the active task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Continue with tool evidence, a workflow, or a decision guide related to this task.

Inspect installation, authentication, structured output, command risk, and official evidence.