Horton

Re: pg_upgrade fails to detect unsupported arrays and ranges

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@enterprisedb.com>
Date: 2021-04-28T21:44:15Z
Lists: pgsql-hackers 
Daniel Gustafsson <daniel@yesql.se> writes:
> On 28 Apr 2021, at 22:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This wording is copied-and-pasted from the other similar tests.  I agree
>> that it's advocating a solution that might be overkill, but if we change
>> it we should also change the existing messages.  

> Good point.

>> I don't mind doing that in HEAD; less sure about the back branches, as

> I think it would be helpful for users to try and give slightly more expanded
> advice while (obviously) still always being safe.  I’m happy to take a crack at
> that once back unless someone beats me to it.

Seems like s/remove the problem tables/drop the problem columns/
is easy and sufficient.

>> (I think) these are translatable strings.

> If they aren't I think we should try and make them so to as far as we can
> reduce language barrier problems in such important messages.

Checking, I see they do appear in pg_upgrade's po files.  So I propose
that we change the existing messages in HEAD but not the back branches.

			regards, tom lane

Commits

  1. Improve wording of some pg_upgrade failure reports.

  2. Fix some more omissions in pg_upgrade's tests for non-upgradable types.

  3. Handle arrays and ranges in pg_upgrade's test for non-upgradable types.