Fix statement rollback discarding the whole transaction on a syntax error (#203)

[davecramer]

Problem

With statement-level rollback (Protocol=7.4-2, the default on PG >= 8.0), a statement that fails with a syntax error silently rolls back the entire transaction instead of just the failing statement -- discarding work already done in that transaction. The reporter observed a table LOCK obtained earlier being released, and the transaction ID advancing, after a malformed LOCK ... IN POTATOS MODE.

Confusingly, other errors (undefined relation, type-coercion, undefined column, etc.) behaved correctly -- only syntax errors triggered it -- which made it look like "a lottery."

Fixes #203.

Root cause

To save a round-trip, the driver established the per-statement internal SAVEPOINT by prepending it to the user's statement and sending them as a single simple-query string:

RELEASE _EXEC_SVP_x; SAVEPOINT _EXEC_SVP_x; <user statement>

PostgreSQL parses a simple-query string in full before executing any of it. A statement that fails at parse time -- a syntax error (SQLSTATE 42601) -- fails the whole string, so the leading SAVEPOINT never runs. With no savepoint established, statement-level rollback has nothing to roll back to, and the driver falls back to aborting the whole transaction.

Execution-time errors (missing relation, bad value, etc.) are unaffected, because parsing succeeds and the SAVEPOINT executes before the failing statement is analyzed. That parse-time-vs-execution-time split is what made this look inconsistent.

Fix

Send the internal SAVEPOINT as its own round-trip, before the user's statement, rather than bundling them into one parse unit (SetStatementSvp in execute.c). The savepoint is then guaranteed to be in place before the statement is parsed, so a syntax error rolls back only that statement and the transaction stays usable.

Also removes the now-unreachable prepend machinery (PREPEND_IN_PROGRESS and its handling in CC_send_query_append).

Performance impact

This changes savepoint establishment from bundled (0 extra messages) to a separate round-trip, so it adds one extra round-trip for every statement except the first in a transaction, under Protocol=7.4-2 with autocommit off. This is a proactive savepoint taken before nearly every statement -- not only before ones that fail -- and it includes read SELECTs.

Measured wire traffic for INSERT; INSERT; SELECT; INSERT (autocommit off, 7.4-2):

Before -- 5 round-trips (savepoint bundled with each statement):

BEGIN;INSERT INTO rt VALUES (1)
SAVEPOINT ...;INSERT INTO rt VALUES (2)
RELEASE ...;SAVEPOINT ...;SELECT count(*) FROM rt
RELEASE ...;SAVEPOINT ...;INSERT INTO rt VALUES (3)
ROLLBACK

After -- 8 round-trips (savepoint sent separately):

BEGIN;INSERT INTO rt VALUES (1)
SAVEPOINT ...
INSERT INTO rt VALUES (2)
RELEASE ...;SAVEPOINT ...
SELECT count(*) FROM rt
RELEASE ...;SAVEPOINT ...
INSERT INTO rt VALUES (3)
ROLLBACK

So an N-statement transaction incurs roughly N-1 extra round-trips (nearly 2x the message count). On a high-latency link this is a real slowdown. It is the price of correctness -- the previous behavior could silently discard work already done in a transaction.

Not affected: the first statement of each transaction (bundled with BEGIN), autocommit-on connections, and Protocol=7.4-0/7.4-1 (no statement-level rollback, no savepoints).

A future optimization could restore the single round-trip by piggybacking the next statement's SAVEPOINT onto the previous statement's send; that is a larger change and is intentionally out of scope here. Maintainer input welcome on whether to ship this straightforward fix now and optimize later, or gate the old bundling behavior behind an option.

Testing

Verified against PostgreSQL 18 via unixODBC.

• New rollback-syntax-error-test: inserts a row, triggers a syntax error, and asserts the row survives (statement-only rollback) -- plus an execution-time-error guard.
• Extended error-rollback-test with an error-class matrix under 7.4-2: three error classes (42601 syntax, 42P01 undefined relation, 22P02 bad value) x two execution paths (SQLExecDirect, SQLPrepare/SQLExecute) x UseServerSidePrepare 0/1, each asserting a marker row survives. This is the coverage gap that let the bug through -- the pre-existing test only exercised execution-time errors.

Both tests fail on main (row/transaction lost on syntax error) and pass with this change. Existing transaction/cursor/error regression tests remain green (the one params diff is a pre-existing PG18 baseline mismatch, confirmed identical on the unmodified driver).