Re: In-order pg_dump (or in-order COPY TO)

On Wed, Aug 27, 2025 at 10:42 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ron Johnson <ronljohnsonjr(at)gmail(dot)com> writes:
> > On Wed, Aug 27, 2025 at 10:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Don't use --format=custom (and not -v either). That causes pg_dump to
> >> include the OIDs and pg_dump object IDs of all the tables and other
> >> objects,
>
> > That's interesting. Why? (Since isn't it supposed to be Bad to rely on
> > OIDs?)
>
> -v in a text-format dump includes that data for debugging purposes:
>
> --
> -- TOC entry 1401 (class 1255 OID 16499)
> -- Name: fipshash(text); Type: FUNCTION; Schema: public; Owner: postgres
> --
>
> (The "TOC entry" comment line wouldn't be there without -v.)
> Then custom format has to store the same info so that pg_restore
> can produce this identical text output on demand.
>

Ah, so the culprit is "-v". I like using -v, redirecting it to a log file
(more info is almost always better), but then I rarely use pg_dump, and
never pipe it to de-duplicators. (ExaGrid is supposed to deduplicate, but
that's not going to stop me from using pgbackrest, compression and
encryption; PCI auditors care about that, not deduplication.)

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!