Re: pg_upgrade fails to detect unsupported arrays and ranges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade fails to detect unsupported arrays and ranges
Date
Msg-id 2940601.1619642871@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade fails to detect unsupported arrays and ranges  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: pg_upgrade fails to detect unsupported arrays and ranges
List pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 28 Apr 2021, at 17:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> +        pg_fatal("Your installation contains system-defined composite type(s) in user tables.\n"
>> +                 "These type OIDs are not stable across PostgreSQL versions,\n"
>> +                 "so this cluster cannot currently be upgraded.  You can\n"
>> +                 "remove the problem tables and restart the upgrade.\n"
>> +                 "A list of the problem columns is in the file:\n"

> Would it be helpful to inform the user that they can alter/drop just the
> problematic columns as a potentially less scary alternative to dropping the
> entire table?

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.  I don't mind doing
that in HEAD; less sure about the back branches, as (I think) these
are translatable strings.

Thoughts?

>> -         * The type of interest might be wrapped in a domain, array,
>> +         * The types of interest might be wrapped in a domain, array,

> Shouldn't this be "type(s)” as in the other changes here?

Fair enough.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Replication slot stats misgivings
Next
From: Daniel Gustafsson
Date:
Subject: Re: pg_upgrade fails to detect unsupported arrays and ranges