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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: In-order pg_dump (or in-order COPY TO)
Date: 2025-08-27 14:42:57
Message-ID: 1392027.1756305777@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

Yeah, this is all pretty historical, but nobody wants to change it
at this point.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2025-08-27 15:12:50 Re: In-order pg_dump (or in-order COPY TO)
Previous Message Ron Johnson 2025-08-27 14:31:24 Re: In-order pg_dump (or in-order COPY TO)