Partial SQL Query Completion Prompt Template

Use this prompt when a model output containing a SQL query has been cut off by token limits, streaming interruptions, or early stopping, and you need to recover a syntactically valid, executable statement without altering the original intent. The primary user is a data engineer or backend developer who has received a partial SELECT, INSERT, UPDATE, or DELETE statement—often truncated mid-clause—and must complete it for downstream execution against a known database schema. This is not a text-to-SQL generation prompt; it assumes the model already understood the query intent and produced a partial statement that needs structural repair, not semantic reinterpretation.

The prompt works best when you can supply the partial SQL text, the target SQL dialect (e.g., PostgreSQL, MySQL, T-SQL), and the relevant table schemas or DDL. Without schema context, the model may hallucinate column names or infer incorrect join conditions. Do not use this prompt for queries that were truncated before any meaningful clause was produced—if you only have SELECT and nothing else, there is no recoverable intent. Similarly, avoid this prompt when the partial output contains ambiguous or contradictory logic; in those cases, flag for human review rather than attempting automated completion.

Before wiring this into a production pipeline, define clear acceptance criteria: the completed query must parse successfully against the target SQL dialect, reference only columns and tables present in the provided schema, and preserve all filtering, joining, and aggregation logic present in the partial input. The harness should include a syntax validator, a schema-reference checker, and an optional EXPLAIN plan sanity check to catch nonsensical completions. Always log the original partial input alongside the completed output for auditability, and escalate to a human when the model cannot produce a valid completion within two retry attempts.

This prompt template recovers partial SQL statements that were cut off by token limits, streaming interruptions, or model early-stopping. It takes a truncated SQL fragment and the original generation context, then produces a syntactically valid, executable completion that respects the partial intent without altering existing clauses. Use this when your data pipeline receives incomplete SELECT, JOIN, WHERE, or other SQL clauses from model outputs and needs them repaired before execution against a database.

textCopy
You are a SQL completion engine. Your task is to complete a truncated SQL statement into a valid, executable query.

## INPUT
Partial SQL fragment (may end mid-clause):
[PARTIAL_SQL]

## CONTEXT
Original task that generated this SQL:
[ORIGINAL_TASK]

Target SQL dialect:
[SQL_DIALECT]

Schema context (tables, columns, types):
[SCHEMA_CONTEXT]

## CONSTRAINTS
- Preserve all existing tokens in the partial SQL exactly as written. Do not modify, reorder, or delete any part of the provided fragment.
- Complete only the truncated portion. If the fragment ends mid-keyword, mid-identifier, or mid-expression, finish that element before adding any missing clauses.
- Produce a single, syntactically valid SQL statement that can be parsed and executed against the target dialect.
- Do not add clauses, columns, joins, or conditions that are not implied by the partial fragment and the original task context.
- If the partial SQL already contains a complete statement, return it unchanged.
- If the fragment is too ambiguous to complete safely, output a JSON object with "status": "unrecoverable" and "reason": "<explanation>" instead of guessing.

## OUTPUT FORMAT
Return ONLY the completed SQL statement, with no markdown fences, no explanations, and no preamble. If unrecoverable, return ONLY the JSON object described above.

## EXAMPLES

Example 1:
Partial SQL: SELECT user_id, email, created_at FROM users WHERE
Original Task: Get all active users who signed up in the last 30 days
Schema: users(user_id INT, email VARCHAR, created_at TIMESTAMP, status VARCHAR)
Completed SQL: SELECT user_id, email, created_at FROM users WHERE status = 'active' AND created_at >= NOW() - INTERVAL '30 days'

Example 2:
Partial SQL: SELECT o.order_id, c.name, o.total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.
Original Task: Find orders over $500 from the current quarter
Schema: orders(order_id INT, customer_id INT, total DECIMAL, order_date DATE), customers(id INT, name VARCHAR)
Completed SQL: SELECT o.order_id, c.name, o.total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.total > 500 AND o.order_date >= DATE_TRUNC('quarter', CURRENT_DATE)

Example 3:
Partial SQL: SELECT * FROM products WHERE category = 'electronics' AND price
Original Task: (not provided)
Schema: products(id INT, name VARCHAR, category VARCHAR, price DECIMAL, stock INT)
Completed SQL: {"status": "unrecoverable", "reason": "price condition is ambiguous without original task context—could be less than, greater than, equals, or range comparison"}

Adapt this template by replacing the schema context with your actual table definitions, including column types and relationships. The [ORIGINAL_TASK] placeholder is critical for disambiguation—without it, the model cannot infer the intended WHERE conditions, JOIN logic, or aggregation behavior. If your pipeline doesn't capture the original generation task, modify the constraints section to request a conservative completion that only closes open syntactic elements without adding semantic conditions. For high-risk environments where incorrect SQL could modify data, add an explicit constraint requiring the completed query to be read-only (SELECT only) or add a [RISK_LEVEL] placeholder that gates whether INSERT/UPDATE/DELETE completions are permitted.

Wiring this prompt into an application requires treating it as a recovery step inside a larger SQL generation or repair pipeline, not as a standalone endpoint. The typical flow begins when a model output is flagged as truncated—either by detecting that the response ended mid-token, by checking that the finish_reason is length or max_tokens, or by failing a SQL syntax parser on the raw output. The partial SQL string is extracted and passed into this prompt's [PARTIAL_SQL] placeholder, along with the original [SCHEMA_CONTEXT] (table definitions, column types, foreign keys) and the [ORIGINAL_REQUEST] that produced the partial query. The prompt returns a completed SQL statement, which must then pass through a series of validation gates before it reaches any database execution layer.

The validation harness should include at minimum three checks. First, a syntax validation using the target database's SQL parser (e.g., sqlparse for generic checks, or a dialect-specific parser like pglast for PostgreSQL, sqlfluff for linting). If the completed query fails to parse, the system should retry the prompt once with the parser error message appended to [CONSTRAINTS]. Second, a schema compliance check that verifies all referenced tables, columns, and aliases exist in the provided [SCHEMA_CONTEXT]—this catches hallucinated column names that the completion step might introduce. Third, a query-plan sanity check using EXPLAIN (without executing the query) to detect cartesian products, missing join conditions, or impossible WHERE clauses. If any check fails, log the failure with the partial input, completed output, and validation error for debugging, then either retry with richer context or escalate for human review depending on your [RISK_LEVEL] configuration.

For production deployment, wrap the prompt call in a circuit breaker that limits retries to a configurable maximum (recommended: 2 retries). Use structured logging to capture the finish_reason of the completion call, the parser result, and any schema drift between the original and completed query. If your application executes the repaired SQL automatically, add a mandatory row-count or runtime guard—for example, reject any completed query whose EXPLAIN output estimates more than [MAX_ROWS] or whose planned execution time exceeds [MAX_QUERY_MS]. For read-only workloads, consider running the completed query in a transaction that is rolled back after extracting the result schema to verify column alignment before committing. Never execute a repaired query against a production write database without human approval unless the [RISK_LEVEL] is explicitly set to low and the query type is restricted to SELECT.

Model choice matters here. Use a model with strong SQL generation capabilities and a context window large enough to hold the full schema context plus the partial query. For most production pipelines, a model like gpt-4o or claude-sonnet-4-20250514 provides reliable completion quality. If latency is critical, consider a smaller fine-tuned model trained specifically on your schema and query patterns. In all cases, monitor the completion's token usage—if the completed query itself approaches the model's output token limit, you may need to split the schema context or use a model with a larger output window. The next step after implementing this harness is to build a regression test suite of known truncated queries and verify that the completed outputs are both syntactically valid and semantically equivalent to the intended full queries.