Re: pg_dump versus hash partitioning - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: pg_dump versus hash partitioning
Date
Msg-id CAKFQuwa5X0dVB1h01j8+TD2XyV8H5ptYATHnVkSa8RtrVyb8VQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump versus hash partitioning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 1, 2023 at 3:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Geoghegan <pg@bowt.ie> writes:
> You mentioned "minor releases" here. Who said anything about that?

I did: I'd like to back-patch the fix if possible.  I think changing
the default --load-via-partition-root choice could be back-patchable.

If Robert is resistant to that but would accept it in master,
I'd settle for that in preference to having no fix.
 
 I'm for accepting --load-via-partition-root as the solution to this problem.  I think it is better than doing nothing and, at the moment, I don't see any alternatives to pick from.

As evidenced from the current influx of collation problems related to indexes, we would be foolish to discount the collation issues with just plain text, so limiting this only to the enum case (which is a must-have) doesn't seem wise.

pg_dump should be conservative in what it produces - which in this situation means having minimal environmental dependencies and internal volatility.

In the interest of compatibility, having an escape hatch to do things as they are done today is something we should provide.  We got this one wrong and that is going to cause some pain.  Though at least with the escape hatch we shouldn't be dealing with as many unresolvable complaints as when we back-patched removing the public schema from search_path.

In the worst case, being conservative, the user can always at minimum restore their dump file into a local database and get access to their data in a usable format with minimal hassle.  The few that would like "same table name or bust" behavior because of external or application-specific requirements can still get that behavior.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump versus hash partitioning
Next
From: Tom Lane
Date:
Subject: Re: pg_dump versus hash partitioning