В общем, решились перейти на 8-ю. Посыпалось куча проблем с совместимостью типов данных, навроде если делаешь такие выборки:
1. SELECT SUBSTR(FIELD_TYPE_TIME, 1, 5) - ругается, что надо привести тип TIME к TEXT.
2. SELECT * FROM TABLE WHERE FIELD_TYPE_TEXT=0 - ругается, что нужно взять число в кавычки, т.к. тип поля текстовый.
3. INSERT INTO TABLE (FIELD_TYPE_REAL) VALUES ('') - ругается, что неверное входное значение для поля типа REAL.
и т.п.
Раньше в 7.4 это всё работало. Теперь 8.3 более строгая к синтаксису. Подскажите, кто знает - можно ли решить эту проблему с помощью конфигурации? Так как программ и таблиц уже довольно много (1000 таблиц, 2Гб программного кода), то перелопачивать тонны скриптов представляется задачей довольно трудной. Пытался менять различные опции в файле postgresql.conf в разделе VERSION COMPABILITY но эффекта не добился.
З.Ы. Знаю, что писать запросы надо было не кривыми руками, но прошу высказываться по теме, если есть какие-то варианты.
Или может быть, можно сделать что-то вроде глобального триггера?
Допустим, пользователь также пихает в поле типа РЕАЛ пустое значение '', а глобальный триггер отслеживает любой инсерт или апдейт и заменяет эти кавычки на NULL... только какбы это сделать-то..
На мой взгляд такого делать
На мой взгляд такого делать не надо.
Собственно в том, что вы столкнулись с такими проблемами ничего удивительного нет. Думаю при переходе от Oracle 7.x на Oracle 9.x проблем было бы не меньше. Единственное, что для коммерческих СУБД существуют всякие инструменты миграции, а для PostgreSQL их нет.
Что я бы сделал на вашем месте. Посмотрел бы типовые ошибки, которые возникают при засасывании дампа в новый PostgreSQL. Затем написал бы на Perl'е простую программку, которая как раз и подставит кавычки где нужно, и приведёт типы где нужно. Оставшийся код, которого наверняка после обработки такой программкой останется немного, можно поправить ручками.
Спасибо за внимание к
Спасибо за внимание к проблеме!
Дело в том, что у нас как раз дампится в 7.4 и заливается в 8.3.8 всё на ура! Без ошибок.
Проблемы начинаются, когда дальше пытаемся использовать написанные приложения на ПХП.
Вот смотрите, например такой запрос, исполняемый в ПХП-программе:
INSERT INTO table1 (field1) VALUES ('$variable');
Допустим, пришла пустая $variable, без значения. В этом случае на сервер отпрвляется такой запрос:
INSERT INTO table1 (field1) VALUES ('');
При условии, что field1 - поле типа REAL - база 7.4. такой запрос принимала, и вместо пустых кавычек сама ставила значение NULL. А 8-ка не принимает и ругается на неверное значение для типа REAL.
Программ, написанных по такой схеме- ОЧЕНЬ много. Переделывать тонны скриптов, выискивая там INSERTы и UPDATы с числовыми типами и переделывая переменные, ставя программные проверки на NULL - это дело явно гиблое.
Для того что бы избегать
Для того что бы избегать подобных проблем используют механизм хранимых функций
А можно по-подробнее, что
А можно по-подробнее, что это?
Гиблое дело или нет, но
Гиблое дело или нет, но нормального другого решения я не вижу.
Можно, конечно, попытаться найти (или написать) какой-либо прокси типа как mysql-proxy где можно подменять один запрос другим, но это всё будут подпорки. Всё-таки правильным путём будет исправление кода как бы его много не было. Единственное как я и писал надо попытаться автоматизировать этот процесс.
в общем, в продолжение
в общем, в продолжение темы!
натолкнули меня на мысль преобразования типов путём создания CASTов...
1. Сначала создаю функцию, которая переводила бы пустое текстовое значение '' в 0:
проверяем - работает:
2. создаю сам каст:
CREATE CAST (text AS real) WITH FUNCTION text_to_real(text);
создаётся, однако при попытке получить то, что мне надо, всё равно не хочет работать:
что ж такое, что ещё надо-то?