Mutation that leaves a parquet_table's ROW SET alone: the single-cell validity writers
(%set_null, %clear_null, %compact_validity) and the column-structural operations
(%drop_column, %rename_column, %copy_column, %cast).
Nothing in this file detaches the table (F-mut-7). That is the whole reason it is a
separate file from parquet_tables_rowmutate.f90: adding a column, dropping one, renaming one
or writing one cell leaves every column the same length, so the table can still read the
columns it has not read yet. Only a change to the row set breaks that alignment, and every
such operation lives in the other file. A new procedure added here must preserve that property
-- if it cannot, it belongs next door.
The file split tracks the ROW SET, not pointer stability, and %compact/%reserve are what
make the difference visible. Everywhere else the two coincide: a row-structural change
reallocates storage, so it both detaches and invalidates every %col pointer, while nothing
here did either. %compact and %reserve reallocate storage without changing the row set --
so they belong here (they detach nothing, and a column not yet read can still be read
afterwards) and yet they DO invalidate every outstanding pointer and row handle. They are the
only two procedures in this file that do. Pointer invalidation is therefore the union of
"changes the row set" and "reallocates storage", and only the first half decides which file a
procedure lives in.
The per-kind %set_element writers are generated rather than written here; they live in
parquet_tables_access.f90 alongside %set, whose shape they follow.