Пытаюсь перейти 7.4 на 8.3.8 - проблемы совместимости!

В общем, решились перейти на 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:

CREATE OR REPLACE FUNCTION text_to_real(TEXT) RETURNS REAL AS '
DECLARE
    zero_value FLOAT;
    enter_value ALIAS FOR $1; 
BEGIN
 
IF enter_value=''''  THEN zero_value=0;
ELSE zero_value=enter_value;
END IF;
 
RETURN zero_value;
END;
'
LANGUAGE 'plpgsql';

проверяем - работает:

db=# select text_to_real('');
 text_to_real
--------------
            0
(1 запись)

2. создаю сам каст:
CREATE CAST (text AS real) WITH FUNCTION text_to_real(text);

создаётся, однако при попытке получить то, что мне надо, всё равно не хочет работать:

db=# select ''::real;
ERROR:  неверный входной синтаксис для типа real: ""

что ж такое, что ещё надо-то?

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023