У меня есть хранимая процедура, которая начала сбой без каких-либо причин. Ну, должен быть один, но я не могу его найти!Postgres pg_dump теперь хранимая процедура терпит неудачу из-за boolean
Это процесс, за которым я следил несколько раз раньше, без проблем.
Исходный сервер работает отлично!
Я делаю pg_dump базы данных на исходном сервере и импортировал ее на другой сервер. Это прекрасно, я могу видеть все данные и делать обновления.
Затем я выполнить хранимую процедуру на импортированные базах данных, которая выполняет следующие действия в базе данных, которая имеет 2 идентичных схемы в -
For each table in schema1
Truncate table in schema2
INSERT INTO schema2."table" SELECT * FROM schema1."table" WHERE "Status" in ('A','N');
Next
Однако это дает мне ошибку сейчас, когда он не делал раньше - Ошибки является
*** Ошибка ** *
ОШИБКА: колонка «НВ» имеет логический тип, но выражение имеет тип целого состояния SQL: 42804 Подсказка: Вам нужно будет переписать или отливать выражение.
Почему я получаю это - Единственное различие между последним моментом, когда я выполнял эту процедуру, и на этот раз состоит в том, что в рассматриваемой таблице теперь добавлен дополнительный столбец, поэтому булевский столбец «HBA» не является последним полем , Но тогда зачем это работать в оригинальной базе данных!
Я попытался удалить все данные, отбрасывая и восстанавливая таблицу, все это не работает. Однако, если я удаляю столбец и добавляю его обратно, если работает - есть ли что-то о булевых полях, которые означают, что они должны быть последним полем!
Любая помощь значительно расширена.
Использование Postgres 9.1
'INSERT INTO schema2." Table "SELECT *' Вы пытались избежать '*' и явно называть столбцы, может быть, добавить тип-тип для логического <--> int? – wildplasser
Хотелось бы, но это зацикливается на всей таблице. Я просто запускаю полный набор хранимых процедур, которые воссоздают вторую схему. Теперь хранится процедура! Глядя на базу данных, он перестроил ее с булевым столбцом в качестве последнего столбца. Так что это может быть проблемой. – osmanager
есть слишком много догадок, если вы не показываете структуры ваших исходных и целевых таблиц в точное время, когда оно терпит неудачу. –