From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Subject: Re: pg_dump is broken for partition tablespaces
Date: Wed, 06 Mar 2019 09:36:07 -0500
Message-ID: <16497.1551882967@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com>
References: <CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com>
David Rowley <david.rowley@2ndquadrant.com> writes:
> As far as I can see, the biggest fundamental difference with doing
> things this way will be that the column order of partitions will be
> preserved, where before it would inherit the order of the partitioned
> table. I'm a little unsure if doing this column reordering was an
> intended side-effect or not.
Well, if the normal behavior results in changing the column order,
it'd be necessary to do things differently in --binary-upgrade mode
anyway, because there we *must* preserve column order. I don't know
if what you're describing represents a separate bug for pg_upgrade runs,
but it might. Is there any test case for the situation left behind by
the core regression tests?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, david.rowley@2ndquadrant.com, pgsql-hackers@lists.postgresql.org, alvherre@2ndquadrant.com, andres@anarazel.de
Subject: Re: pg_dump is broken for partition tablespaces
In-Reply-To: <16497.1551882967@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox