different column orders in regression test database

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

Responses

Browse pgsql-hackers by date

  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