]> granicus.if.org Git - postgresql/commit
Fix pg_dump's handling of dependencies for custom opclasses.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 31 Jul 2019 19:42:50 +0000 (15:42 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 31 Jul 2019 19:42:50 +0000 (15:42 -0400)
commit408f759380c723b94e9fb8b523aa02509e1e1d6e
tree54010587cd1825c633718e4cffa16b29e9cb302e
parentc4b7bb3cf19f5d847544de93c36329de8e59193b
Fix pg_dump's handling of dependencies for custom opclasses.

Since pg_dump doesn't treat the member operators and functions of operator
classes/families (that is, the pg_amop and pg_amproc entries, not the
underlying operators/functions) as separate dumpable objects, it missed
their dependency information.  I think this was safe when the code was
designed, because the default object sorting rule emits operators and
functions before opclasses, and there were no dependency types that could
mess that up.  However, the introduction of range types in 9.2 broke it:
now a type can have a dependency on an opclass, allowing dependency rules
to push the opclass before the type and hence before custom operators.
Lacking any information showing that it shouldn't do so, pg_dump emitted
the objects in the wrong order.

Fix by teaching getDependencies() to translate pg_depend entries for
pg_amop/amproc rows to look like dependencies for their parent opfamily.

I added a regression test for this in HEAD/v12, but not further back;
life is too short to fight with 002_pg_dump.pl.

Per bug #15934 from Tom Gottfried.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/15934-58b8c8ab7a09ea15@postgresql.org
src/bin/pg_dump/pg_dump.c
src/bin/pg_dump/t/002_pg_dump.pl