When you dump out the regression test database and load it back in, a
few tables end up with different column orders:
Original:
Table "public.f_star"Column | Type | Collation | Nullable | Default
--------+--------------+-----------+----------+---------class | character(1) | | |aa | integer
| | |cc | name | | |ee | smallint | |
|ff | polygon | | |f | integer | | |e | integer |
| |a | text | | |
Reloaded:
Table "public.f_star"Column | Type | Collation | Nullable | Default
--------+--------------+-----------+----------+---------class | character(1) | | |aa | integer
| | |a | text | | |cc | name | |
|ee | smallint | | |e | integer | | |ff | polygon |
| |f | integer | | |
This table is part of a lengthy inheritance chain, so this might be
intentional or too hard to fix. This behavior goes back to 9.2 and
possibly further.
But this is a bit more suspicious:
Original:
Table "public.mlparted11"Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------b | integer | | not null |a | integer |
| not null |
Partition of: mlparted1 FOR VALUES FROM (2) TO (5)
Reloaded:
Table "public.mlparted11"Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------a | integer | | not null |b | integer |
| not null |
Partition of: mlparted1 FOR VALUES FROM (2) TO (5)
The same applies for other tables in this partitioning group:
public.mlparted12, public.mlparted2, public.mlparted4
But the root table public.mlparted matches on both sides.
While you can create all kinds of dubious messes with general
inheritance, this should probably not be allowed to happen in the
restricted setting of partitioning.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
