PostgreSQL добавляет конечные нули в числовые

Question

Недавно я перенесла DB в PostgreSQL, который имеет несколько столбцов, которые определены как numeric(9,3) и numeric(9,4). При тестировании приложения я обнаружил, что когда данные сохраняются в этих столбцах, к вставленному значению добавляются нулевые нули. Я использую Hibernate, и мои журналы показывают правильные значения, которые создаются для подготовленных операторов.

Пример данных Я вставка является 0.75 в numeric(9,3) колонки, и значение, которое хранится в 0,750. Другой пример для столбца numeric(9,4): Я вставляю значение и БД держится 12.0000.

Я нашел этот родственный вопрос: postgresql numeric type without trailing zeros. Но он не предлагал решения, кроме того, чтобы процитировать документацию 9.x о том, что конечные нули не добавляются. С этим вопросом, ответ привел документы (которые я также читал), который сказал:

Числовых значения физически хранятся без какого-либо дополнительного ведущего или конечных нулей. Таким образом, заявленная точность и масштаб столбца являются максимумами, а не фиксированными распределениями.

Однако, как и этот вопрос, я вижу добавление нужных нулей. Необработанная вставка, сгенерированная Hibernate в журналах, не показывает этот дополнительный багаж. Поэтому я предполагаю, что это сообщение PostgreSQL, которое я не установил правильно, я просто не могу найти, как я ошибался.

Answer 1

Я думаю, что это он, если я понимание «принуждать» правильно в этом контексте. Это из PostgreSQL документов:

И максимальная точность и максимальный масштаб числового столбца могут быть сконфигурирована. Чтобы объявить столбец числового типа использования синтаксис:

NUMERIC(precision, scale) 

точность должна быть положительной, масштаб ноль или положительное. В качестве альтернативы :

NUMERIC(precision) 

выбирает масштаб 0. Указание:

NUMERIC 

без какой-либо точности или масштаба создает столбец в котором числовые значения любой точности и масштаба может быть сохранена, вплоть до предел реализации по точности.Столбец такого типа не будет вводить значения ввода в какой-либо конкретный масштаб, , тогда как числовые столбцы с объявленной шкалой будут принуждать входные значения к этой шкале.

Смелый акцент мой.

Так что в заблуждение позже в том же разделе:

Числовые значения физически храниться без каких-либо дополнительных ведущих или замыкающие нули. Таким образом, заявленная точность и масштаб столбца являются максимумами, а не фиксированными распределениями.

Смелый акцент мой снова.

Это может быть верно для части точности, но поскольку масштаб выполняется принудительно, когда он определен, конечные нули добавляются к входным значениям для соответствия определению шкалы (и я предполагал бы усеченный, если бы слишком большой).

Я использую точность, шкала определения для принудительного принуждения. Во время вставки БД конечные нули добавляются в числовую шкалу, которая, похоже, поддерживает принуждение и конфликтует с утверждением о добавлении нужных нулей.

Правильно или нет, мне пришлось обработать проблему в коде после того, как сделан выбор. К счастью для меня влияющие атрибуты - это BigDecimal, поэтому зачистка конечных нулей была легкой (хотя и не изящной). Если у кого-то есть лучшее предложение о том, что PostgreSQL не добавляет конечные нули в числовую шкалу при вставке, я открыт для них.

Answer 2

Если вы указали точность и масштаб, Pg-пэды для этой точности и масштаба.

regress=> SELECT '0'::NUMERIC(8,4); 
numeric 
--------- 
    0.0000 
(1 row) 

Невозможно отключить это. Это все равно такое же число, и точность определяется типом, а не значением.

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

regress=> SELECT '0'::NUMERIC, '0.0'::NUMERIC; 
numeric | numeric 
---------+--------- 
     0 |  0.0                                        
(1 row)