Docs: put named row access where someone leaving IfxPy will find it

The API reference gained the Row section with the release, which is the
right home for the details and the wrong place to discover the feature
exists. Three gaps closed.

The IfxPy migration guide is the page for people in exactly the position
that prompted this: IfxPy is positional-only, so those codebases grow a
description/zip helper that yields a dict and still no attribute access.
That page now shows the helper it replaces alongside the one-liner, and
notes the .lower() in the hand-written version is already a no-op since
Informix folds unquoted identifiers.

Quickstart gains one sentence, next to the paramstyle note where someone
is already thinking about how rows come back.

The phase log records 2026.09.03, including where the testing actually
found the shadowed-names bug: not in the differential test across twenty
awkward types, which found nothing, but in six lines of name bookkeeping
that were correct when written and stopped being correct an hour later.

Verified live by content, and the #rows anchor the new cross-links point
at resolves.

docs-site/src/content/docs/explain/phase-log.md

@@ -96,6 +96,40 @@ The cheapest fix was also the most valuable. Asserting that a row decoder lands
 
 Test count went from 241 to 457 across three server versions over this stretch.
 
+### 2026.09.03
+
+Two more, one of each kind.
+
+The `:N` placeholder rewriter was a bare regular expression, so it
+rewrote the inside of string literals: `'http://host:8080/x'` was stored
+as `'http://host?/x'`. Same family as the statement-classification bug
+above, and the last place the driver inferred meaning from SQL text
+instead of handling it. Replaced with a scanner using Informix's own
+lexical rules, measured rather than assumed. One of those rules would
+have been got wrong from habit: a backslash escapes nothing, so `'a\'b'`
+is an unterminated string and draws `-282`. A scanner written to
+Postgres reflexes desyncs there and corrupts everything after it.
+
+`row_factory=Row` adds column-name and attribute access, on request from
+a user coming from `pyodbc`. Opt-in, because it costs about 9% on bulk
+fetch and that is not a trade to make for someone who never reads a
+column by name.
+
+Testing the second one found the pattern again, this time in code
+written an hour earlier. The names a column could shadow were
+hand-listed as `count` and `index`, the two `tuple` methods; then `keys`,
+`_asdict` and `_fields` were added to the same class and the list was
+never revisited. A column called `keys` returned a bound method, in
+silence. The fix was to compute the set from the class rather than
+lengthen the list, and to parametrize the test over that computed set so
+it grows with the class.
+
+The interesting part is where testing found it. A differential test
+across twenty columns covering every awkward type, populated and fully
+NULL, found nothing. The bug was in six lines of name bookkeeping that
+looked obviously correct, and had been correct when written. Anything
+that must stay in sync with a class by hand eventually will not.
+
 ## Notable architectural pivots
 
 The decision log calls out four moments where the obvious choice would have been wrong:

docs-site/src/content/docs/how-to/migrate-from-ifxpy.md

@@ -48,6 +48,36 @@ The exception hierarchy is identical: `Error`, `Warning`, `InterfaceError`, `Dat
 - **Type-safe annotations**: `informix-driver` ships with `py.typed`
 - **Python 3.12+ support**
 - **Pipelined `executemany`**: 1.6× faster than IfxPy's per-row implementation
+- **Rows addressable by name**: `row["col"]` and `row.col`, not just `row[0]`
+
+## Reading rows by name
+
+IfxPy gives you positional access and nothing else, which is why most
+IfxPy codebases grow a helper like this:
+
+```python
+cols = [c[0].lower() for c in cur.description]
+row_dict = dict(zip(cols, cur.fetchone()))
+```
+
+That gets you a dict and still no attribute access. Ask for `Row`
+instead and all three work at once:
+
+```python
+conn = informix_db.connect(..., row_factory=informix_db.Row)
+cur.execute("SELECT config_key, config_value FROM settings")
+row = cur.fetchone()
+
+row[0], row["config_key"], row.config_key
+```
+
+Set on the connection, so it applies to every cursor from it. The
+`.lower()` in the hand-written version is already a no-op, incidentally:
+Informix folds unquoted identifiers to lower case.
+
+It is opt-in because it costs about 9% on bulk fetch. See
+[the API reference](/reference/api/#rows) for the numbers and the
+edge cases.
 
 ## Migrating incrementally
 

docs-site/src/content/docs/reference/api.md

@@ -107,6 +107,38 @@ The login response carries Informix's *internal* protocol version, not the relea
 That string is available for free as `server_version_internal`. Because it reads as a wrong answer, `server_version` asks the server for its release with `DBINFO('version','full')`. That is one query on first access, cached for the life of the connection, and it falls back to the internal string rather than raising if no database is open.
 :::
 
+## Rows
+
+Fetch methods return plain tuples by default. Pass `row_factory` to get rows that also answer to a column name and an attribute, the shape `pyodbc` and `mssql-python` provide:
+
+```python
+conn = informix_db.connect(..., row_factory=informix_db.Row)
+cur = conn.cursor()
+cur.execute("SELECT tabid, tabname FROM systables")
+row = cur.fetchone()
+
+row[0]            # 1
+row["tabname"]    # 'systables'
+row.tabname       # 'systables'
+```
+
+Set on the connection, so it applies to every cursor from it. A cursor can override it with `cur.row_factory = informix_db.Row`. Pools and the async API forward it unchanged.
+
+`Row` subclasses `tuple`, so `row == (1, "systables")` is still true and anything treating rows as sequences keeps working. Slices return plain tuples, since a slice has no column map. `row.keys()` gives the column names and `row._asdict()` gives a dict.
+
+:::note[Why it is opt-in]
+On a 20,000-row five-column fetch: 37.2 ms with tuples, 40.8 ms with `Row`, about 9%. Supporting `row["name"]` means `__getitem__` becomes a Python method rather than C-level tuple indexing, which costs roughly 39 ns on every subscript.
+
+Defaulting it on would move the [1.05-1.15x ratio against IfxPy](/start/vs-ifxpy/) to roughly 1.15-1.25x. That is a good trade for readable application code and a bad one for a bulk export that never looks at a column by name, so it is yours to make.
+:::
+
+Four behaviours worth knowing:
+
+- Informix folds unquoted identifiers to lower case, so `SELECT Config_Key` is reachable as `row.config_key`. The `.lower()` people add by hand when building this themselves is already a no-op.
+- Expression columns get server-generated names like `(count(*))`, which cannot be Python attributes. Those are reachable by subscript only.
+- Duplicate column names resolve to the first occurrence, matching `pyodbc`. Positional access still reaches both.
+- **A column beats a method of the same name.** `tuple` defines `count` and `index`; `Row` adds `keys`, `_asdict` and `_fields`. A column with any of those names wins, because otherwise it would hand back a bound method instead of a value. The methods stay reachable as `tuple.count(row, x)` and `Row.keys(row)`.
+
 ## Cursor
 
 | Method / property | Description |

docs-site/src/content/docs/reference/types.md

@@ -45,6 +45,8 @@ Both decode to plain Python `int`, so this only matters if you're reading the wi
 
 `2026.09.02` fixed two more, both found by a new check that verifies each row consumed exactly its own payload. Smart LOBs were read as a flat 72-byte field when they actually occupy 149 bytes populated and 5 when NULL, so a `BLOB` or `CLOB` anywhere but the **last** column shifted every column after it. A NULL `SET` / `MULTISET` / `LIST` / `ROW` skipped its length field and did the same. That release also made a mismatch raise where it happens, naming the column and the byte delta, instead of handing back plausible-looking wrong values.
 
+`2026.09.03` fixed one on the **write** path rather than the read path, which makes it the only entry here that affects data already stored. The `:N` placeholder rewriter was a regular expression and could not see a string literal, so it rewrote the inside of one: `'http://host:8080/x'` was stored as `'http://host?/x'`. Any `HH:MM` time, URL with a port, or `key:value` string was affected, whichever placeholder style you used. If you have written such values through this driver, they are worth checking.
+
 If your schema has `LVARCHAR` columns, `2026.08.27` is not safe. If you select a `BLOB` or `CLOB` in any position other than last, or a nullable collection column, nothing before `2026.09.02` is safe. Upgrade.
 :::
 

docs-site/src/content/docs/start/quickstart.mdx

@@ -121,6 +121,11 @@ with informix_db.connect(host="127.0.0.1", port=9088, user="informix",
 
 `?` and `:1` both work. Informix's native paramstyle is `numeric`, but `?` is supported as a synonym.
 
+Rows come back as plain tuples. If you would rather read them by column
+name, pass `row_factory=informix_db.Row` to `connect()` and you get
+`row["name"]` and `row.name` alongside `row[0]`. See
+[the API reference](/reference/api/#rows).
+
 ## 5. Use the connection pool
 
 For real applications, prefer the pool:

docs-site/src/content/docs/start/wtf.md

@@ -76,7 +76,7 @@ Every finding from a system-wide failure-mode audit (data correctness, wire safe
 
 **0 critical, 0 high, 0 medium audit findings remain.** Every architectural change went through a Margaret Hamilton-style review focused on silent-failure modes, recovery paths, and documented invariants. Each documented invariant is paired with either a runtime guard or a CI tripwire test.
 
-450+ tests across unit / integration / benchmark suites. The integration suite runs against the official IBM Informix Developer Edition Docker images and passes 457/457 on 15.0.1.0.3DE and 14.10.FC7W1DE, and 456/457 on 12.10.FC12W1DE (the single skip is a common table expression, which 12.10 predates). `make test-matrix` runs the lot.
+470+ tests across unit / integration / benchmark suites. The integration suite runs against the official IBM Informix Developer Edition Docker images and passes 472/472 on 15.0.1.0.3DE and 14.10.FC7W1DE, and 471/472 on 12.10.FC12W1DE (the single skip is a common table expression, which 12.10 predates). `make test-matrix` runs the lot.
 
 That matrix exists because it turned out to be needed. A user reported corrupted result sets on Informix 12; the cause was three framing bugs that affected every version including the one we tested against, and they'd survived because no fixture used the affected types. Testing one server and inferring the rest is how that happens.