Refactor jq/result paths for spaniter v0.2.0

[apstndb]

Summary

• Adopt unreleased spaniter APIs via local replace until apstndb/spaniter#6 ships as v0.3.0 (WithStatsEncoding, RowIteratorResult.StatsProto / ResultSet, PullRowIteratorSeq).
• Add resultset package for RowIterator → *sppb.ResultSet materialization (Materialize, FromIteratorResult, CollectListValues, RowToListValue).
• Slim jqresult to jq-specific concerns: protojson maps, lazy/eager gojq pipeline, RowToJSON.
• Drive lazy RowIter through PullRowIteratorSeq with WithResult; Stop() stops the pull sequence when started, otherwise stops the raw iterator directly.
• Coerce read-write jq to eager materialization before jq so DML executes even when the filter ignores input (for example true).
• Pass WithStatsEncoding(DMLExact) for executed read-write DML via spaniterStatsOpts; PLAN mode keeps default encoding so row_count_exact: 0 is not fabricated.
• Propagate terminal iterator errors from PullRowIteratorSeq through lazy RowIter.

Merge note: This PR depends on spaniter v0.3.0. Merge spaniter#6 first, then bump go.mod to the released tag and remove replace. GitHub CI build/lint will fail until then because the published v0.2.0 module does not include these APIs.

Test plan

• go test ./... (with local replace github.com/apstndb/spaniter => ../spaniter)
• go test -run TestWithCloudSpannerEmulator . (emulator)
• read-write lazy DML executes with filter true and preserves rowCountExact: "0" for zero-row UPDATE
• PLAN DML materialization omits fabricated rowCountExact
• jqresult lazy unit tests (stats deferral, duplicate .rows, Stop without drain, terminal error propagation)
• resultset / protojson DML zero-row-count stats tests

[gemini-code-assist]

Code Review

This pull request refactors the codebase to extract the logic for draining Cloud Spanner row iterators into a new resultset package, utilizing the updated spaniter v0.2.0 library. It also updates jqresult.RowIter to stream rows using Go's iter.Pull2 sequence mechanism. Feedback on the changes highlights a potential goroutine leak in RowIter.Stop(). When r.stopSeq is non-nil, the method returns early without calling r.rowIter.Stop(), which could leave the background goroutine blocked on an active Spanner network call. It is recommended to ensure r.rowIter.Stop() is always called to properly release resources.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[apstndb]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the codebase to extract result set materialization logic into a new resultset package, which leverages the updated github.com/apstndb/spaniter dependency (v0.2.0). The jqresult package has been updated to use spaniter sequences and pull-based iteration for row streaming, and to handle DML-specific statistics correctly via a new dml parameter. Additionally, obsolete helper functions in main.go have been removed, and comprehensive unit tests have been added for the new and refactored components. I have no feedback to provide as there are no review comments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[apstndb]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the jqresult package to leverage spaniter's iterator sequence and introduces a new resultset package to handle draining Cloud Spanner row iterators into protobuf ResultSets. It also adds support for preserving standard DML row counts and ensuring lazy JQ filters fully consume the RowIterator during read-write transactions. A review comment identified a potential bug in the test helper runLazyReadWriteDML where retrying a transaction could lead to duplicate elements in the output slice; resetting the slice inside the transaction block was suggested to resolve this.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

In Cloud Spanner, the transaction function passed to ReadWriteTransaction can be executed multiple times if the transaction aborts and retries. Since out is declared outside the transaction scope and appended to inside the transaction, retrying will result in duplicate elements in out. Resetting out to nil at the start of the transaction function ensures that retries do not accumulate duplicate values.

Suggested change

	var out []any
	_, err := client.ReadWriteTransaction(ctx, func(ctx context.Context, tx *spanner.ReadWriteTransaction) error {
	rowIter := tx.QueryWithOptions(ctx, spanner.Statement{SQL: sql}, spanner.QueryOptions{})
	var out []any
	_, err := client.ReadWriteTransaction(ctx, func(ctx context.Context, tx *spanner.ReadWriteTransaction) error {
	out = nil
	rowIter := tx.QueryWithOptions(ctx, spanner.Statement{SQL: sql}, spanner.QueryOptions{})