From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | different column orders in regression test database |
Date: | 2017-05-18 19:21:44 |
Message-ID: | 2b9db0d4-9812-b541-122d-dd3464c45325@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-05-18 19:23:02 | Re: 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32" |
Previous Message | Peter Eisentraut | 2017-05-18 19:14:18 | Re: 10beta1 sequence regression failure on sparc64 |