Claude, Redshift API.
A 200 from ExecuteStatement means Redshift accepted the SQL, not that it ran correctly. The video shows how to poll DescribeStatement to a terminal state and decode result cells with to_entries[0].value.
Someone sees a 200 back from Redshift and assumes the query worked. The video explains why that assumption is wrong: a 200 from the Data API only means the query began. Whether it actually finished, and whether it succeeded, shows up later. The video walks through how to set up a call, how to check the outcome, and how to read the results.
A 200 means accepted
Redshift's Data API hands back an ID rather than rows. It is not a result, just an ID to check later. The video makes the point with a deliberate example: send SQL with a typo and ExecuteStatement still returns 200. The failure only appears when you poll DescribeStatement and see Status: FAILED. It never shows up in the response to the call that submitted the query.
What must be set before any call
Two things have to be in place first. The first is the region, which is baked into the endpoint hostname. The second is a connection target in one of three shapes: a workgroup name for Serverless, a cluster plus a database user for provisioned access, or a secret for Secrets Manager.
With the workgroup set, the video submits a real query: the top twenty events from the past month, grouped by name. ExecuteStatement hands back exactly one thing, an ID.
Polling to a terminal state
That same ID goes to DescribeStatement, which is polled until the statement reaches FINISHED. Only then should you check HasResultSet before calling GetStatementResult, because a write statement can finish with nothing to page.
The video adds that FINISHED alone is not proof the SQL was clean. The same status field can read FAILED instead, and only DescribeStatement, never the original call, says so. A statement still sitting at STARTED is not stuck either. That is exactly what the poll loop is for.
Decoding result cells
One habit carries past this particular query. Each result cell should be decoded with to_entries[0].value. A plain .value silently returns nothing, which makes the failure easy to miss because no error accompanies it.
The two habits that govern every query
The video's carry-out compresses everything into two habits. Poll DescribeStatement to a terminal state before ever calling GetStatementResult, and decode each cell with to_entries[0].value instead of a naive .value. Get those right, and a 200 from ExecuteStatement stops meaning anything it does not.
Key takeaways
- A 200 from
ExecuteStatementmeans the query was accepted, not that it ran correctly. - The call returns only an ID, which you use to check the outcome later.
- SQL errors surface only through
DescribeStatementasStatus: FAILED. - Set the region and a connection target first: workgroup for Serverless, cluster plus database user for provisioned, or a Secrets Manager secret.
- Poll
DescribeStatementuntil a terminal state, and treatSTARTEDas normal rather than stuck. - Check
HasResultSetbeforeGetStatementResult, since writes can finish with nothing to page. - Decode cells with
to_entries[0].value, because a naive.valuereturns nothing.
Try it yourself
Ask Claude to query your Redshift Serverless workgroup for the top twenty events from the past month, grouped by name. Then watch three things. Does it set the region and the workgroup before making any call? Does it poll DescribeStatement to a terminal state before calling GetStatementResult? And does it read result cells with to_entries[0].value rather than a .value that comes back empty?
Chapters
Full transcript(auto-generated, with timestamps)
A 200 from Redshift means my query worked. Right?
[0:00]Someone assumes a 200 back from Redshift means their query worked. It doesn't. 200 only means the query began. Whether it actually finished comes later. So, did it really work? Submit a query and
200 means accepted, not correct
[0:11]Redshift's Data API hands back an ID, not rows, not a result, just an ID to check later. Send SQL with a typo and execute statement still returns 200. Only polling describe statement later reveals status failed. The failure never shows up in the response to the call that submitted it. Two things have to be set
Region + RS_TARGET, then submit
[0:30]Before any call: the region baked into the endpoint hostname and a connection target in one shape, a workgroup name for serverless, a cluster plus a database user for provisioned access, or a secret for Secrets Manager. Set the workgroup and submit the real query, the top 20 events from the past month grouped by name, and execute statement hands back exactly one thing, an ID. Poll that same ID with describe
Finished isn't proof it succeeded
[0:51]Statement until it reaches finished, then check has result set before calling get statement result. A write statement can finish with nothing to page. But, finished alone doesn't mean the SQL was clean. That same field can read failed instead, and only describe statement, never the original call, ever says so. A statement still sitting at started isn't stuck, either. That's what the poll loop is for. One habit that carries past this one query, decode each cell with to entries bracket zero.value. A plain .value silently returns nothing.
Carry-out
[1:21]Every Redshift query cloud runs turns on two habits. Poll describe statement to a terminal state before ever calling get statement result, and decode each cell with to entries bracket zero.value instead of a naive .value get those right, and a 200 from execute statement stops meaning anything it doesn't. Your
Your turn
[1:39]Turn. Here's the prompt. Read it with me. Query my Redshift serverless workgroup. Find the top 20 events from the past month grouped by name. Watch three things. Does it set the region and the workgroup before making any call? Does it poll describe statement to a terminal state before ever calling get statement result? And does it read the result cells with to entries bracket zero.value instead of naive.value that comes back empty. Layam Inforbear Claude
Outro
[2:03]Redshift API Layam Inforbear
