Округление ROUND в Postgres не банковское, а обычное арифметическое, и реализовано правильно. В данном же случае на первый план выступает неявное приведение результата арифметической операции к типу исходных операндов. Другими словами, результат деления двух целых чисел приводится к целому. Причем приводится не округлением (ROUND), а усечением (TRUNC).

Например,
100/51.0 = 1.9607843137254902
100/51 = 1

Самое противное, что этот принцип применяется не ко всему выражению в целом, а к каждой паре операндов, с начала вычисления. То есть, для 100/51*51.0 сначала вычисляется 100/51, приводится к целой единице, а потом умножается на 51.0, и получаем 51.0

100/51*51.0 = 51.0

В то же время, если один из первых двух операндов будет вещественным, то и результат их не усечется, и дельнейшие вычисления пойдут верно:

100/51.0*51 = 100.0000000000000002

Двойка за пределами значащих разрядов - неизбежное следствие погрешностей машинной арифметики, и легко убирается тем же ROUND.

Поэтому, если есть желание вести вычисления с вещественными числами, лучше сразу привести все аргументы к вещественному типу, а для подавления мусора за пределами значащих цифр использовать округление ROUND.

Да, действительно, все зависит от того, каким типом считается 1.5

SELECT
1100/100*(1.5::numeric),
1100/100*(1.5::float),
ROUND(1100/100*(1.5::numeric)),
ROUND(1100/100*(1.5::float))
;

?column? | ?column? | round | round
----------+----------+-------+-------
16.5 | 16.5 | 17 | 16

Суть в том, что 1.5 не может точно втиснуться в тип float, и в результате получается что-то вроде 16.49999999999..., округляемое до 16.0. А при выведении на экран применяется некое форматирование (не строгое округление), прячущее эти подробности, и сбивающее с толку непосвященных.

То есть при приведении к numeric считает правильно. И по умолчанию 1.5 приводится к numeric (Chapter 10. Type Conversion, 10.3. Functions, Example 10-4. Rounding Function Argument Type Resolution, "...Since numeric constants with decimal points are initially assigned the type numeric..."). В общем-то все логично. Потому что:

"The type numeric can store numbers with up to 1000 digits of precision and perform calculations exactly. It is especially recommended for storing monetary amounts and other quantities where exactness is required".

А про это ваше там float вааще говорят (Chapter 8. Data Types, 8.1.3. Floating-Point Types):

"If you require exact storage and calculations (such as for monetary amounts), use the numeric type instead".

А теперь скажите, что Вы считаете, и почему выбрали float?

>>> и максимум был бы он с двумя знаками после запятой, из этих соображений казалось бы и float-а хватит

float - это не только ограничение на количество значащих цифр, но и специфическое внутреннее представление, накладывающее свои ограничения. Какие именно? Попробуйте на бумажке выразить число 0.1 в двоичном виде, (точнее, в представлении с плавающей запятой) - и увидите. Получите бесконечный хвост, точно как при попытке записать 10/3 десятичной дробью. Разумеется, при втискивании в конкретные ячейки этот хвост приходится где-то обрезать, внося погрешность уже при присвоении значения переменной.

>>> а ващще все суммы храню в копейках

в numeric можно хранить и в рублях.