Re: pg_upgrade fails to detect unsupported arrays and ranges
От | Daniel Gustafsson |
---|---|
Тема | Re: pg_upgrade fails to detect unsupported arrays and ranges |
Дата | |
Msg-id | 37F95EC7-9557-4273-A274-A51D565C6B4A@yesql.se обсуждение исходный текст |
Ответ на | Re: pg_upgrade fails to detect unsupported arrays and ranges (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_upgrade fails to detect unsupported arrays and ranges
|
Список | pgsql-hackers |
> On 28 Apr 2021, at 22:47, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. 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. > (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. -- Daniel Gustafsson https://vmware.com/
В списке pgsql-hackers по дате отправления: