## Code Analysis

### Scalar loop conversion errors are returned directly
`server/plpgsql/interpreter_logic.go:498-515`
```go
case OpCode_ForQueryNext:
	// ...
	if len(operation.SecondaryData) > 0 {
		err = stack.UpdateVariables(ctx, operation.SecondaryData, schema, row)
	} else {
		err = stack.UpdateRecord(operation.Target, schema, row)
	}
	if err != nil {
		return nil, err
	}
```
The scalar loop path calls `UpdateVariables` and returns its error directly from the interpreter call.

`server/plpgsql/interpreter_stack.go:584-601`
```go
func (is *InterpreterStack) UpdateVariables(ctx *sql.Context, names []string, schema sql.Schema, row sql.Row) error {
	// ...
	value, _, err := iv.Type.Convert(ctx, row[i])
	if err != nil {
		return err
	}
	iv.Value = value
	// ...
}
```
An input that cannot be converted to the declared scalar type therefore exits this path as an error. The source excerpt establishes the error path; it does not by itself establish how the server handles the error at the client connection boundary.

### Observed execution

The same authenticated `psql` connection invoked the invalid function and then two valid calls:

```sh
PGPASSWORD=[REDACTED] psql -h 127.0.0.1 -p 5432 -U postgres -d postgres -X -v ON_ERROR_STOP=0 -a -P format=unaligned -P tuples_only -c "SELECT 'FAIL_CALL', bf_fail_scalar(); SELECT 'VALID_CALL_1', bf_valid_scalar(); SELECT 'VALID_CALL_2', bf_valid_scalar();"
```

```text
ERROR:  integer: unhandled type: string
SELECT 'FAIL_CALL', bf_fail_scalar(); SELECT 'VALID_CALL_1', bf_valid_scalar(); SELECT 'VALID_CALL_2', bf_valid_scalar();
```

# No VALID_CALL_1 or VALID_CALL_2 result was emitted.
# Server log: connection closed immediately after error `integer: unhandled type: string`.

### Result
The captured run supports the reported failure: the invalid scalar loop produced the conversion error, the same connection closed immediately afterward, and neither subsequent valid call produced a result. The source path shows the conversion error originates in scalar `FOR ... IN SELECT` assignment and is returned directly by the loop interpreter.

### Test context
The functions were created in separate authenticated `psql` commands before the final same-connection trigger. No stubs, mocks, or bypasses were applied.