2013-09-11 2 views
0

У меня есть хранимая процедура, которая начала сбой без каких-либо причин. Ну, должен быть один, но я не могу его найти!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

+0

'INSERT INTO schema2." Table "SELECT *' Вы пытались избежать '*' и явно называть столбцы, может быть, добавить тип-тип для логического <--> int? – wildplasser

+0

Хотелось бы, но это зацикливается на всей таблице. Я просто запускаю полный набор хранимых процедур, которые воссоздают вторую схему. Теперь хранится процедура! Глядя на базу данных, он перестроил ее с булевым столбцом в качестве последнего столбца. Так что это может быть проблемой. – osmanager

+0

есть слишком много догадок, если вы не показываете структуры ваших исходных и целевых таблиц в точное время, когда оно терпит неудачу. –

ответ

0

Проблема здесь - столы в разных схемах имели разный порядок столбцов.

Если вы не указали явно список столбцов и порядок в INSERT INTO table(...) или используете SELECT * - вы полагаетесь на порядок столбцов таблицы (и теперь вы видите, почему это плохо).

Вы пытаетесь сделать что-то вроде

INSERT INTO schema2.table1(id, bool_column, int_column) -- based on the order of columns in schema2.table1 
select id, int_column, bool_column -- based on the order of columns in schema1.table1 
from schema1.table1; 

И такой запрос вызвал ошибку произнесения, поскольку тип столбца missmatch.

+0

Вы правы - я нашел, если я перестроил таблицы в schema2 на основе schema1 с нуля - то есть, сбросив их и заново создав их, теперь хранится процедура. – osmanager

+0

Я думаю, что дамп psql изменил структуру таблиц как число таблиц INHERIT из родительских таблиц, таким образом, порядок не может быть гарантирован, но восстановление их происходит. Спасибо за вашу помощь. – osmanager

Смежные вопросы