slpНаписал

CREATE OR REPLACE FUNCTION to_number(character varying)
RETURNS numeric AS
$BODY$select to_number($1,'99999');$BODY$
LANGUAGE 'sql' IMMUTABLE;
ALTER FUNCTION to_number(character varying) OWNER TO postgres;

Создал индекс

CREATE UNIQUE INDEX dogovornumber2
ON contragentteplo
USING btree
(to_number(dogovor), period_id);


Но новая беда
select * from contragentteplo where 12433=to_number(dogovor)
индекс подключает

select * from contragentteplo where 12433=to_number(dogovor,'99999')
индекс не подключает
что вообщем-то правильно

НО у меня масса запрсов именно с to_number(dogovor,'99999')
Как обхитрить Postgresql ?

Как его заставить при to_number(dogovor,'99999') подключать индекс dogovornumber2 ?

Неохота менять тексты
А ничего что это разные функции? То, что они одинаково называется еще не значит что одинаково работают

Может так:
Ня?

Perederiyпочитай первый пост
выдает

Точно. Я чего-то перепутал, что этот тунумбер - самописный .

Perederiy
фунции в идексном выражении должны быть помечены как IMMUTABLE

в 8.2
в 8.1 работает
Т.е. есть куча уже работающих запросов, которые нельзя менять.
И в них используется to_number(,)?
Которая с 8.2 уже не IMMUTABLE.

Возникла идея (проверить смогу в лучшем случае к вечеру) - может пересоздать эту функцию как IMMUTABLE. Если получится - будет прикольно

Perederiyтебе прикольно
а мне как вспомню сколько надо менять - сразу резко плохеет

ЗЫ Нафига было это менять в 8.2 ???
Вроде краем уха видел - что там бывают проблемы из серии "если гад пользователь меняет локаль во время выполнения запроса".

Таки нашел.


(C) дока

slpи что из этого следует ?
как практически поступить в моем случае ?
Хм. Я правильно подозреваю единость в двух лицах?
Попробовать пересоздать функцию с указением того, что она IMMUTABLE.
Если не поможет - то таки создавать свою функцию на эту тему, и по ней ваять индекс.
Я других вариантов не вижу. Может гуру чего подскажут другого.

MBGСидеть на 8.1 и не дергаться. Зачем переносить корректно работающую систему на новую версию? Вот начинать проекты да, лучше на 8.2 или 8.3 в зависимости от планируемого срока разработки.
Ну, переносить - например из-за повышения производительности и надежности.
Кроме того, судя по моей ссылке, на любой новой базе эта ошибка будет повторятся, ибо это был багфикс в 8.1.6 (и кста глубоко вниз до 7.3 кажется).
предлогаемый Вами путь - вечно висеть на 8.1.5 для новых instance + апгрейд до текущей. Кривовато в общем.
С другой стороны, если система в пром и на доработку ресурсы не выделяются (деньги, время и т.д.) то можно оставить и так.

ЗЫ Придумал еще один "зверский" вариант.
ВНИМАНИЕ! За последствия ОТВЕСТВЕННОСТИ НЕ НЕСУ И НЕ ХОЧУ НЕСТИ!!!
После этого индекс создаётся. Судя по коментам - проблема в lc_numeric, т.е. если его не трогать, то всё должно быть ОК, а если трогать то ясен пень - капец.

ЗЗЫ Полезная вещь - исходники