pg_dump does not preserve pgcolumnar per-table options (set_options / encode_effort)

[ChronicallyJD]

Gap

Per-table options set through pgcolumnar.set_options (e.g. encode_effort) do not survive pg_dump / restore. They live in the pgcolumnar.options catalog rather than as reloptions, so pg_dump does not emit them; after a dump-and-restore the table silently reverts to default options.

Confirmed by the new test/pg_dump_roundtrip.sh (data, access method, and index round-trip cleanly; the option does not):

-- per-table option encode_effort: before='fast' after=''

Why it matters

A restored table silently loses its tuning (encode_effort, and any future per-table option). That is a data-fidelity surprise on the basic backup/restore path, and it compounds the cross-boundary durability gaps in #239 (pg_upgrade) and #241 (physical replication), where the same side-catalog state is at risk.

Options

• Register pgcolumnar.options (and any other user-visible per-table catalog) as an extension config table via pg_extension_config_dump, so its rows are included in pg_dump. This is the standard mechanism for extension-owned tables that hold user data.
• Or store the options as reloptions on the table so core dumps them.
• Or, at minimum, document the limitation in docs/administration.md / docs/limitations.md so operators reload options after a restore.

The round-trip suite reports this rather than asserting it, so it stays visible without gating red until it is addressed.

Found in a release-readiness review; surfaced by test/pg_dump_roundtrip.sh.