JelisТак что "перевести всю бд с флоута на нумерик" не такая уж и ужасная идея (хотя, это смотря какая база) - с float мучиться придеться больше.кажецца сильно потеряем в скорости арифметики (агрегирования). т.ч. можно оставить флоаты, но затригеренные по бефоре (типо каст к нужной точности нумерика). и с раундом (если потербуется), переопределенным через каст в ньюмерик. Вопрос: можно ли единожды создать свой тип из флоата, определив, что он перед соханением должен каститься в ньюмерик с нужным числом знаков на хвосте, (и взад на автомате) (и переопределив round для него)?


JelisИ вообще, float - это одна из главных и наибольших "засад" начинающего программиста. Его ж даже сравнивать в принципе нельзя! опять таки, если не свободен в выборе компонентов для типа (я например перегоняю данные из/через аксесс - юзая ODBC) то засад несколько больше. например если обновлять запись из интерморды акса, имеющую поля с типом timestamp(tz), то велика вероятность напороться на сообщение "запись изменена другим пользоваетем") которая проистекает из того, что реальный запрос на апдейт уходит с перечислением значений всех полученных полей в WHERE, а точность данных в аксесовском DATE/TIME (реально -это float8) много меньше точности в timestampe, и искомая строка для обновления не находится сервером. Приходится пользовать на стороне pg тип abstime для дат и времени (якобы устаревший) или перед сохранением в timestampt заранее огрублять его в триггере BEFORE UPDATE (new.timefield = new.timefield::abstime) - чтобы сравнение давало "совпадение" строк. Т.я. флоаты то как раз сравниваются, а вот флаты с более точными - нет (или надо пририсовывать правило нечеткого сравнения типов в ODBC-ю).