feat(db.sqlite): add Row.names, get_string/get_int, and improve exec_map#26702
Merged
JalonSolov merged 1 commit intovlang:masterfrom Mar 8, 2026
Merged
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5e7e8863f7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
quaesitor-scientiam
force-pushed
the
enhance/sqlite-row-named-access
branch
3 times, most recently
from
4acc2bd to
e0663f2
Compare
Collaborator
|
A conflict to resolve... possibly from your other PR? |
Add `names []string` to `Row` so callers can access column values by
name rather than by hardcoded index. Column names are captured once
after sqlite3_prepare_v2 (before stepping) and the same slice is
assigned to every row, avoiding per-row allocation overhead.
`names` is placed after `vals` to preserve positional struct literal
compatibility — `Row{['a', 'b']}` continues to populate `vals`.
Add `get_string(col_name string) string` and `get_int(col_name string)
int` accessor methods on `Row`. Both return zero values gracefully when
the column name is not found, preserving compatibility with manually
constructed Row instances that have no names.
Improve exec_map to capture column names once before the row loop
instead of calling sqlite3_column_name on every column of every row.
For a result set of N rows and C columns this reduces sqlite3_column_name
calls from N*C to C.
Closes vlang#26701
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
quaesitor-scientiam
force-pushed
the
enhance/sqlite-row-named-access
branch
from
e0663f2 to
d97ba9e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
names []stringtoRow— populated byexecandexec_param_manyaftersqlite3_prepare_v2, shared across all rows in a result setget_string(col_name string) stringandget_int(col_name string) intaccessor methods onRowexec_mapto capture column names once before the row loop instead of on every row iterationMotivation
Rowpreviously only exposedvals []string, requiring callers to hardcode column positions from the originatingSELECT. Any reordering of columns would silently break lookups.exec_mapprovided name-based access but at the cost of a map allocation per row and redundantsqlite3_column_namecalls on every row.Design
Column names are available from
sqlite3_column_nameimmediately aftersqlite3_prepare_v2— before anysqlite3_stepcall. Names are captured into a single[]stringslice and the same slice is assigned to everyRowin the result set. V slices share the backing array, so there is no per-row name allocation overhead.get_stringandget_intperform a linear scan ofr.names, which is acceptable for typical SQL result sets (small number of columns). Both return zero values gracefully whennamesis empty (manually constructedRowinstances).Impact on existing callers
Row{vals: [...]}andRow{}constructions are unaffected;namesdefaults to[]string{}and all existingrow.vals[i]access is unchanged.exec_mapcallers see no API change — same return type and values, fewersqlite3_column_namecalls.Test plan
vlib/db/sqlite/tests pass (6 passed, 1 skipped — skip is pre-existing and unrelated)Closes #26701