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
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) |