fix: return proper error instead of assertion when portal format codes are too short (#173071)

[waterWang]

Summary

Fixes #173071

When a portal prepared from an EXECUTE wrapper outlives a result-shape change, the format codes sized at Bind time (from the wrapper's frozen column count) may not cover the columns the plan actually produces at Execute time. This causes an assertion failure in GetFormatCode():

SQLSTATE[XX000]: Internal error: ERROR: internal error: could not find format code for column 1 in [FormatText]

Root Cause

The EXECUTE handler in execStmtInOpenState replaces the wrapper statement with the inner prepared statement's data. The inner statement's ExpectedTypes is refreshed from the re-prepared inner statement, so the plan-time guard passes. However, the format codes on the portal were sized at Bind time from the wrapper's frozen Columns, which may still reflect the old schema.

Changes

1. pkg/sql/pgwire/command_result.go: Changed errors.AssertionFailedf to errors.Newf in GetFormatCode() — the mismatch is a recoverable error, not an assertion violation.

2. pkg/sql/conn_executor.go: In initStatementResult(), when GetFormatCode() returns an error (format codes too short for the result columns), convert it to a pgcode.FeatureNotSupported error (0A000 cached plan must not change result type) — matching the error code returned by the non-EXECUTE Bind-time guard.

Reproduction

See the test case in the issue: PREPARE bar AS SELECT * FROM v WHERE id = 1 → ALTER TABLE v ADD COLUMN b INT → DEALLOCATE bar; PREPARE bar AS SELECT * FROM v, b → EXECUTE bar on a portal bound before the DDL.

Impact

Intermittent XX000 internal errors surfaced to application clients using the extended query protocol (server-side prepared statements) on long-lived pooled connections after schema migrations.

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

Thank you for contributing to CockroachDB. Please ensure you have followed the guidelines for creating a PR.

Before a member of our team reviews your PR, I have some potential action items for you:

• We notice you have more than one commit in your PR. We try break logical changes into separate commits, but commits such as "fix typo" or "address review commits" should be squashed into one commit and pushed with --force
• Please ensure your git commit message contains a release note.
• When CI has completed, please ensure no errors have appeared.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroachlabs-cla-agent]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}