Server-file privilege model has drifted: docs claim superuser, two functions require only a role, and the boundary test covers neither

[jdatcmd]

docs/administration.md:239 states:

Every one of them requires superuser, enforced in C at the point of use

That is no longer true on main, and the test that would have caught it does not
cover the functions that broke it.

The state on main

function	gate	in the docs table	in server_file_privilege.sh
import_parquet, read_parquet, parquet_schema, export_parquet, the Arrow pair	superuser()	yes	yes
file_split_offsets	has_privs_of_role(..., ROLE_PG_READ_SERVER_FILES)	no	no
parallel_copy	same role check	no	no

grep -n "parallel_copy\|file_split_offsets" docs/administration.md returns
nothing, and the same grep over test/server_file_privilege.sh returns nothing.

So two server-file functions on main sit outside the documented model and outside
the privilege boundary test. A non-superuser holding pg_read_server_files can
read a server file through parallel_copy and cannot through import_parquet:
the same capability behind two different bars.

How it got here

I raised this reviewing #323 and marked it "reported, not reproduced". It merged
without being addressed, which is on me for not carrying it forward. PR #329
(parallel_export_parquet, gated on pg_write_server_files) would add a third,
and its author flagged the inconsistency in the PR body rather than letting it
pass silently.

What to decide, not just fix

The role gate is arguably the better model: it is what core COPY FROM 'file'
uses, and pg_read_server_files/pg_write_server_files exist precisely so the
capability can be granted without superuser. The problem is not which bar is right,
it is that there are two bars and the documentation asserts one.

1. Standardise on the role checks and relax the older functions. A deliberate
   privilege loosening, so it needs saying out loud in the docs and the CHANGELOG.
2. Standardise on superuser() and tighten the two newer functions. Breaking
   for anyone already using them, though they are days old.
3. Keep both deliberately and document why. Weakest option: the split does not
   track anything a user would predict.

Whichever is chosen, two things follow:

• docs/administration.md needs the blanket sentence replaced and the table
  completed.
• test/server_file_privilege.sh should be data-driven over the full set, so a new
  server-file function without a privilege check fails the gate instead of slipping
  past it. That is the durable half. The docs drifted once already and this issue
  is the evidence they will again.

[ChronicallyJD]

Took this — PR #331.

Went with option 1 (standardize on the roles, matching core COPY ... FROM/TO 'file'):

• the seven superuser() checks relaxed to pg_read_server_files (readers) / pg_write_server_files (writers); parallel_copy/file_split_offsets/parallel_export_parquet already role-gated;
• docs/administration.md — blanket sentence replaced, table completed with all ten entry points;
• CHANGELOG — the deliberate-loosening entry;
• test/server_file_privilege.sh rebuilt over the full set, with a coverage check that turns red if a SQL function declaring a file-path argument is missing from the list — the durable half you asked for. 30/30.

Gate green: preflight 0-warning on 15–19, matrix ALL VERSIONS PASSED, and every server-file suite passes.

One call is yours: option 1 widens the untrusted Parquet/Arrow reader functions (import_parquet, read_parquet, parquet_schema, the FDW, import_arrow) from superuser to pg_read_server_files while Arrow parser fuzzing (#214) is still open — the exact thing #216 held at superuser. I implemented it because you leaned that way and it is the coherent model, and documented the exposure. If you'd rather keep those readers at superuser for now and role-gate only the writers + the text-path readers (parallel_copy, file_split_offsets, which use core's trusted COPY parser), that is a one-line-per-site change — say so and I'll adjust #331.

Stacked on #329 (the export_parquet refactor + parallel_export_parquet live there).