Я, например, считаю - и моя локальная база с этим согласна - что в mysql вовсе нет синтаксиса ALTER COLUMN id cast(11 as int) и, следовательно, этот alter table можно просто выбросить как ничего не делающий на исходной базе будучи синтаксически некорректным.
Именно потому и нужно "зачем".
Если вы переносите базу - то вам не нужен modify. Создавайте таблицу сразу в нужном конечном виде.
Если это вялотекущий долговременный перенос и нужно стянуть изменения схемы в апстриме - то понимать какая схема таблицы была - надо.
Напишите команду полностью. В mysql нет команд, начинающихся со слова MODIFY. Могу предположить, что речь об alter table - а потому напишите ещё зачем вы это хотите делать и какова структура таблицы до того.
Потому что SQL стандарт предписывает при обращении через unquoted identifier приводить идентификатор в определённый регистр принудительно.
Таблица называется Couriers, так допустимо именовать идентификатор. Но только как quoted identifier с точки зрения синтаксиса.
Потому что это всё, согласно синтаксису идентификаторов, обращение к одной и той же таблице couriers. Назвали таблицу не в том регистре - соизвольте теперь к ней всегда обращаться синтаксически корректно. См. ссылку на документацию, там объяснено.
Делаете как положено, штатными средствами export\import баз.
как лучше перетащить на новый raid Postgres
Заострю внимание: в пределах одного сервера.
Ну вот сами и объясняйте как сделать initdb, с какими ключами, как запустить два инстанса postgresql параллельно, где потом править PGDATA на новое местоположение в системных сервисах (с учётом используемой ос и init'а, в дебианах systemctl edit postgresql.service скорей всего уведёт не туда куда надо). Ну, ничего сложного, конечно. Но зачем?
Определите для начала, кто именно перестал запускаться. postgresql или всё-таки pgadmin. Это разные в принципе проекты. Если сама база - то приведите лог попытки старта.
Наоборот. Если, разве что, не поросили --no-acl явным образом сами. Но, что важно, сохраняются конкретные GRANT, при том сами упоминаемые роли предварительно не создаются. Если их нет в базе при восстановлении - будут ошибки восстановления.
Исключение - pg_dumpall, где переносятся и пользователи тоже.
Я, например, считаю - и моя локальная база с этим согласна - что в mysql вовсе нет синтаксиса ALTER COLUMN id cast(11 as int) и, следовательно, этот alter table можно просто выбросить как ничего не делающий на исходной базе будучи синтаксически некорректным.