postgres_fdw: Use COPY to speed up batch inserts

Incremental Update: v13 Patchset — Switch Back to TEXT Format with Refactored Escaping

Key Change: CSV → TEXT format reversal, with code deduplication

Matheus posted a new patchset (v13) that reverses the previous decision to use CSV format and returns to TEXT format for the COPY stream. The critical difference from earlier TEXT attempts is that the escaping logic is no longer duplicated — it's extracted from the core COPY TO code path into a reusable function.

0001 — Refactor CopyAttributeOutText into a reusable utility:

• Extracts the TEXT-mode escaping logic (handling of tabs, newlines, backslashes, \N for NULL) from the COPY TO routine into a standalone function that can be called by both COPY TO internally and by postgres_fdw.
• This addresses the earlier objection (from Sawada and Vondra) that the postgres_fdw patch was reimplementing/duplicating CopyAttributeOutText-equivalent code, creating a maintenance burden and divergence risk.

0002 — Main feature patch using TEXT format with shared escaping:

• The COPY-based batch insert now uses TEXT format, calling the refactored escaping function from 0001.
• Removes the resultRelInfo->ri_WithCheckOptions == NIL check that had been reintroduced by mistake in a prior version (already flagged as unnecessary in earlier review).

Why This Matters

The FORMAT choice (TEXT vs CSV vs BINARY) was a significant design decision in earlier rounds. CSV had "won" because it was deemed simpler to implement correctly. This revision argues that with the escaping logic properly factored out of core into a shared function, TEXT format is equally correct and avoids the overhead/complexity of CSV quoting. It also means postgres_fdw's escaping stays in sync with core COPY automatically — if core's CopyAttributeOutText logic changes, the shared function changes for both callers.

No Other Substantive Technical Discussion

The second message is simply a cross-reference pointing a reviewer to the new patchset. No new reviewers, no new technical arguments, and no benchmark data accompanies this revision.