Sql error 42883 ошибка функция round double precision integer не существует

I am in the middle of migrating some queries which have been running for ages with MySQL database which is now in Postgres having the same structure. I got stuck with a simple round function which ends with the following error message.

ERROR: function round(double precision, integer) does not exist

part of the select which does not work:

round(floor(pools.available_capacity_in_kb/1024/1024/1024*100)/100,2) as free,

pools.available_capacity_in_kb is stored as BIGINT in the database (Postgres 10.9)

funnydman

7,9393 gold badges32 silver badges51 bronze badges

asked Nov 6, 2019 at 14:03

radek lopateckiradek lopatecki

5231 gold badge4 silver badges5 bronze badges

I had the same problem with geograpic coordinates. The longitude was in double precision from the open street map data and needed a rouded value.

My solution work fine:

select ROUND(CAST(longitude AS numeric),2) from my_points;

answered Mar 25, 2021 at 13:11

Besides the type CAST syntax, you can use the following syntax to convert a value of one type into another (cast :: operator):

select ROUND(value::numeric, 2) from table_x;

Notice that the cast syntax with the cast operator (::) is PostgreSQL-specific and does not conform to the SQL standard.

answered Aug 8, 2021 at 11:15

funnydmanfunnydman

7,9393 gold badges32 silver badges51 bronze badges

The core of the problem is somewhere else. PostgreSQL uses long division for integer and bigint numbers (when on both parts of division are int, bigint values). So result of pools.available_capacity_in_kb/1024/1024/1024*100)/100 is bigint. Probably this is not, what you expect.

postgres=# df round
                          List of functions
+------------+-------+------------------+---------------------+------+
|   Schema   | Name  | Result data type | Argument data types | Type |
+------------+-------+------------------+---------------------+------+
| pg_catalog | round | double precision | double precision    | func |
| pg_catalog | round | numeric          | numeric             | func |
| pg_catalog | round | numeric          | numeric, integer    | func |
+------------+-------+------------------+---------------------+------+
(3 rows)

There is not any round function for bigint (because it has not any sense).
Please try to fix it by using float division like

pools.available_capacity_in_kb/1024/1024/1024*100)/100.0

Now, the result will be numeric, and the function round(numeric, int) exists — so it should works.

Dave Yu

1862 silver badges14 bronze badges

answered Nov 6, 2019 at 14:18

Pavel StehulePavel Stehule

40.5k5 gold badges88 silver badges89 bronze badges

you can use following syntax as well

select round((value::Decimal),2) from table_name;

Notice that the cast syntax with the cast operator (::) is PostgreSQL-specific and does not conform to the SQL standard.

answered Sep 24, 2022 at 16:31

j kj k

111 silver badge5 bronze badges

Источник

написал запрос

select
              'request_median_duration' as metric_name,
              EXTRACT(EPOCH FROM request_median_duration)/60 as metric_value,
              TO_CHAR(NOW(), 'YYYY-MM-DD HH:MM:SS') as push_dttm
              from mp_statistics

нужно округлить до 2 знака до запятой
попробовал сделать так

select
              'request_median_duration' as metric_name,
              ROUND(EXTRACT(EPOCH FROM request_median_duration)/60,2) as metric_value,
              TO_CHAR(NOW(), 'YYYY-MM-DD HH:MM:SS') as push_dttm
              from mp_statistics

возвращается ошибка

SQL Error [42883]: ERROR: function round(double precision, integer) does not exist
  Подсказка: No function matches the given name and argument types. You might need to add explicit type casts.
  Позиция: 94

выкрутился так

select
              'request_median_duration' as metric_name,
              ROUND(EXTRACT(EPOCH FROM request_median_duration)/60*100)/100 as metric_value,
              TO_CHAR(NOW(), 'YYYY-MM-DD HH:MM:SS') as push_dttm
              from mp_statistics

какой есть еще более изящный вариант?

Источник

Hi,

I use the function Number.Round in Power query. It works fine when used from Power BI Desktop

But when I try to refresh the report in Power BI Services (embedded licence), I get the following error :

Data source errorDataSource.Error: PostgreSQL : 42883: function round(double precision, integer) does not exist. DataSourceKind = PostgreSQL. DataSourcePath = ************. Message = 42883: function round(double precision, integer) does not exist. ErrorCode = -2147467259</pii>. . The exception was raised by the IDbCommand interface. Table: rejets

Here is my power query :

let Source = PostgreSQL.Database(«*******************),
technique_job_reject = Source{[Schema=»technique»,Item=»job_reject»]}[Data],
#»Filtered Rows1″ = Table.SelectRows(technique_job_reject, each true),
#»Added Custom» = Table.AddColumn(#»Filtered Rows1″, «Rounded RejectTime», each Number.Round(Number.From([reject_time])*24*60*60,0)/(24*60*60)),
#»Changed Type» = Table.TransformColumnTypes(#»Added Custom»,{{«Rounded RejectTime», type datetime}}),
#»Removed Columns» = Table.RemoveColumns(#»Changed Type»,{«reject_time»}),
#»Renamed Columns» = Table.RenameColumns(#»Removed Columns»,{{«Rounded RejectTime», «Date rejet»}})
in #»Renamed Columns»

Can someone help me ?

Источник

Попробуйте также старый синтаксис для кастинга,

SELECT ROUND(AVG(some_column)::numeric,2)    
FROM table;

работает с любой версией PostgreSQL.

В некоторых функциях PostgreSQL есть недостатки, почему (???): Я думаю, что «это недостаток» (!), но @CraigRinger, @Catcall и команда PostgreSQL согласитесь о «историческом обосновании».

PS: еще один вопрос о округлении — точность, проверьте @Ответ IanKenney.

Перегрузка как стратегия литья

Вы можете overload использовать функцию ROUND с помощью

 CREATE FUNCTION ROUND(float,int) RETURNS NUMERIC AS $$
    SELECT ROUND($1::numeric,$2);
 $$ language SQL IMMUTABLE;

Теперь ваша инструкция будет работать нормально, попробуйте (после создания функции)

 SELECT round(1/3.,4); -- 0.3333 numeric

но он возвращает тип NUMERIC… Чтобы сохранить первую перегрузку использования commom, мы можем вернуть FLOAT-тип, когда предлагается параметр TEXT,

 CREATE FUNCTION ROUND(float, text, int DEFAULT 0) 
 RETURNS FLOAT AS $$
    SELECT CASE WHEN $2='dec'
                THEN ROUND($1::numeric,$3)::float
                -- ... WHEN $2='hex' THEN ... WHEN $2='bin' THEN... complete!
                ELSE 'NaN'::float  -- like an error message 
            END;
 $$ language SQL IMMUTABLE;

Try

 SELECT round(1/3.,'dec',4);   -- 0.3333 float!
 SELECT round(2.8+1/3.,'dec',1); -- 3.1 float!
 SELECT round(2.8+1/3.,'dec'::text); -- need to cast string? pg bug

PS: проверка df round после перегрузок отобразит что-то вроде

 Schema     |  Name | Result data type | Argument data types 
------------+-------+------------------+----------------------------
 myschema   | round | double precision | double precision, text, int
 myschema   | round | numeric          | double precision, int
 pg_catalog | round | double precision | double precision            
 pg_catalog | round | numeric          | numeric   
 pg_catalog | round | numeric          | numeric, int

Функции pg_catalog являются стандартными, см. руководство по встроенным математическим функциям.

Источник

As the documentation says:

The trigger function must be defined before the trigger itself can be
created. The trigger function must be declared as a function taking
no arguments and returning type trigger. (The trigger function
receives its input through a specially-passed TriggerData structure,
not in the form of ordinary function arguments.)

The function you have declared is:

insertIntoAutoIncrementExample(companyname text,location text) ... returns void

so it does not fit both in the return type and in the argument types.
A trigger function does not take arguments but can access the values inserted or changed in the row variables NEW and OLD. They get automatically defined in plpgsql, see Trigger procedures in the plpgsql chapter for details and examples.

Concerning the error message:

function insertintoautoincrementexample() does not exist

it means: this function name, with an empty list of arguments, does not exist.
The presence of parentheses around nothing is relevant, because in postgresql, functions always go with their argument types:
foobar(int) is not the same function than foobar(), or foobar(int,int) or foobar(text).

Источник

This is with a PostgreSQL backend … we gave the following round functions available:

PDOException: SQLSTATE[42883]: Undefined function: 7 ERROR: function round(double precision, integer) does not exist LINE 2: ROUND(6371 * ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts.: SELECT icao, name AS real_name, ROUND(6371 * ACOS( SIN(RADIANS(:lat)) * SIN(RADIANS(latitude)) + COS(RADIANS(:lat)) * COS(RADIANS(latitude)) * COS(RADIANS(longitude — :long)) ), 1) AS distance, MOD( ROUND( DEGREES( ATAN2( SIN(RADIANS(longitude — :long)) * COS(RADIANS(latitude)), COS(RADIANS(:lat)) * SIN(RADIANS(latitude)) — SIN(RADIANS(:lat)) * COS(RADIANS(latitude)) * COS(RADIANS(longitude — :long)) ) ) ) + 360, 360 ) AS bearing FROM {weather_icao} ORDER BY distance; Array ( [:lat] => 8.9667 [:long] => -79.5333 ) in weather_get_nearest_station() (line 564 of /usr/local/www/d_admin/bestseniorsinfo.com/www/sites/all/modules/weather/weather.module).

Tag1 supports the Drupal Project. Tag1 logo

Источник

With current master, the postgresql tests fail with this error (among others):

====================================================================
PostGIS(1): Query: DECLARE qgis_1166 BINARY CURSOR FOR SELECT "key1"::text,"key2"::text,"pk"::text,"cnt"::text,"name"::text,"name2"::text,"num_char"::text FROM "qgis_test"."someDataCompound" WHERE (round(("cnt" / ((66.67)::real)),0) <= 2) returned 7 [ERROR:  function round(double precision, integer) does not exist                                        ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
]
PostGIS(1): 1 cursor states lost.
SQL: DECLARE qgis_1166 BINARY CURSOR FOR SELECT "key1"::text,"key2"::text,"pk"::text,"cnt"::text,"name"::text,"name2"::text,"num_char"::text FROM "qgis_test"."someDataCompound" WHERE (round(("cnt" / ((66.67)::real)),0) <= 2)
LINE 1: ...::text FROM "qgis_test"."someDataCompound" WHERE (round(("cn...
                                                    ==
FAIL: testStyleDatabaseWithService (__main__.TestPyQgsPostgresProvider)
Test saving style in DB using a service file.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/qgis/qgis-master/tests/src/python/test_provider_postgres.py", line 1318, in testStyleDatabaseWithService
    self.assertEqual(len(ids), 1)
AssertionError: 0 != 1

I’m running it against PostgreSQL-9.6.9
Indeed round(float8, int) does not exist, while round(numeric, int) does:

strk=# select round(1.01::float8, 2);
ERROR:  function round(double precision, integer) does not exist
LINE 1: select round(1.01::float8, 2);
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
strk=# select round(1.01::numeric, 2);
 round
-------
  1.01
(1 row)

strk=# select version();
                                             version                                              
--------------------------------------------------------------------------------------------------
 PostgreSQL 9.6.9 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0, 64-bit
(1 row)

Источник

ERROR: function round(double precision, integer) does not exist #31495

Comments

strk commented Aug 29, 2019

With current master, the postgresql tests fail with this error (among others):

I’m running it against PostgreSQL-9.6.9
Indeed round(float8, int) does not exist, while round(numeric, int) does:

The text was updated successfully, but these errors were encountered:

gioman commented Jan 31, 2021

@strk is this still relevant?

github-actions bot commented Feb 15, 2021

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as «stale».
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

MorriganR commented May 25, 2021

github-actions bot commented Jul 14, 2021

github-actions bot commented Aug 12, 2021

While we hate to see this happen, this issue has been automatically closed because it has not had any activity in the last 42 days despite being marked as feedback. If this issue should be reconsidered, please follow the guidelines in the previous comment and reopen this issue.
Or, if you have any further questions, there are also further support channels that can help you.

Источник

Sql error 42883 ошибка функция round double precision integer не существует

I am in the middle of migration some queries which have been running for ages with MySQL database which is now in Postgres having the same structure. Я нахожусь в процессе миграции некоторых запросов, которые выполнялись целую вечность с базой данных MySQL, которая теперь находится в Postgres и имеет ту же структуру. I got stuck with simple round function which ends with the following error message. Я застрял с простой функцией раунда, которая заканчивается следующим сообщением об ошибке.

ERROR: function round(double precision, integer) does not exist ОШИБКА: функция round(двойная точность, целое число) не существует

part of the select which does not work: часть выбора, которая не работает:

pools.available_capacity_in_kb is stored as BIGINT in the database (Postgres 10.9) pools.available_capacity_in_kb хранится в базе данных как BIGINT (Postgres 10.9)

Ответы

I had the same problem with geograpic coordinates. У меня была такая же проблема с географическими координатами. The longitude was in double precision from the open street map data and needed a rouded value. Долгота была получена с двойной точностью из данных открытой карты улиц и нуждалась в округленном значении.

My solution work fine: Мое решение работает нормально:

Besides the type CAST syntax, you can use the following syntax to convert a value of one type into another (cast :: operator): Помимо синтаксиса типа CAST, вы можете использовать следующий синтаксис для преобразования значения одного типа в другой (оператор приведения ::):

Notice that the cast syntax with the cast operator (::) is PostgreSQL-specific and does not conform to the SQL standard. Обратите внимание, что синтаксис приведения с оператором приведения (::) специфичен для PostgreSQL и не соответствует стандарту SQL.

The core of the problem is somewhere else. Суть проблемы в другом. PostgreSQL uses long division for integer and bigint numbers (when on both parts of division are int, bigint values). PostgreSQL использует длинное деление для целых чисел и чисел bigint (когда в обеих частях деления стоят значения int, bigint). So result of pools.available_capacity_in_kb/1024/1024/1024*100)/100 is bigint. Таким образом, результатом pools.available_capacity_in_kb/1024/1024/1024*100)/100 является bigint. Probably this is not, what you expect. Вероятно, это не то, что вы ожидаете.

There is not any round function for bigint (because it has not any sense). Никакой функции round для bigint не существует (потому что в ней нет никакого смысла). Please try to fix it by using float division like Пожалуйста, попробуйте исправить это, используя деление с плавающей запятой, например

Now, the result will be numeric , and the function round(numeric, int) exists — so it should works. Теперь результатом будет numeric , а функция round(numeric, int) существует, так что она должна работать.

Связанные вопросы

Отменить часть миллисекунды из отметки времени

Выбрать первую строку в каждой группе GROUP BY?

Как мне (или я могу) ВЫБРАТЬ DISTINCT для нескольких столбцов?

Как выбрать n-ю строку в таблице базы данных SQL?

Сохранение вывода PL / pgSQL из PostgreSQL в файл CSV

Извлечь дату (гггг / мм / дд) из метки времени в PostgreSQL

Источник

Как округлить среднее значение до 2 знаков после запятой в PostgreSQL?

Я использую PostgreSQL через Ruby gem ‘sequel’.

Я пытаюсь округлить до двух знаков после запятой.

Я получаю следующую ошибку:

Я не получаю ошибку, когда я запускаю следующий код:

кто-нибудь знает, что я делаю неправильно?

5 ответов:

PostgreSQL не определяет round(double precision, integer) . По причинам @Catcall объясняет в комментариях, версия раунда, который принимает точность доступна только для numeric .

(в приведенном выше, обратите внимание, что float8 это просто сокращенный псевдоним для double precision . Вы можете видеть, что PostgreSQL расширяет его в выводе).

вы должны привести значение, которое будет округлено до numeric использовать форму с двумя аргументами round . Просто добавьте ::numeric для стенографии, например round(val::numeric,2) .

если вы форматируете для отображения пользователю, не используйте round . Используйте to_char (см.: функции форматирования данных типа в руководстве), который позволяет задать формат и дает вам text результат, который не зависит от того, какие странности ваш клиентский язык может сделать с numeric значения. Например:

to_char округлит числа для вас как часть форматирования. Элемент FM префикс сообщает to_char что вы не хочу никаких прокладок с ведущими пробелами.

попробуйте также старый синтаксис для литья,

работает с любой версией PostgreSQL.

есть недостаток перегрузок в некоторых функциях PostgreSQL, почему (. ): Я думаю, что «это недостаток» (!), но @CraigRinger, @Catcall и команда PostgreSQL согласны с «историческим обоснованием pg».

PS: еще один момент о округлении точность, Регистрация @IanKenney по ответ.

перегрузка как стратегия кастинга

вы можете перегрузка круглая функция с,

теперь ваша инструкция будет работать нормально, попробуйте (после создания) функция

но он возвращает числовой тип. Чтобы сохранить первую перегрузку commom-usage, мы можем вернуть тип FLOAT, когда предлагается текстовый параметр,

PS: проверка df round после перегрузки, покажет что-то вроде

Источник

Sql error 42883 ошибка функция round double precision integer не существует

function avg(double precision, integer) does not exist(((
function round(double precision, integer) does not exist(((((

Не хотит такого

А что за проблемы вот два мануала по AVG и ROUND, вроде должно прокатить
«возраст» должен быть целый или numeric
http://www.postgresql.org/docs/8.2/s. aggregate.html
http://www.postgresql.org/docs/7.2/s. ions-math.html

add — и вся конструкция в SELECT-е должна быть само собой

ERROR: function round(double precision, integer) does not exist
HINT: No function matches the given name and argument types. You may need to add explicit type casts.

когда то давным-давно возникла подобная (не точно такая, но суть тоже в потере точности) проблема в FoxPro (FPD 2.6)

попробуйте такой код:

если он не даст требуемого результата, тогда попробуйте такой код:

Источник

Как округлить среднее значение до 2 знаков после запятой в PostgreSQL?

Я использую PostgreSQL через «продолжение» драгоценного камня Ruby.

Я пытаюсь округлить до двух знаков после запятой.

Я получаю следующее сообщение об ошибке:

Я не получаю ошибки, когда запускаю следующий код:

Кто-нибудь знает, что я делаю не так?

Ваше сообщение об ошибке не соответствует коду в вашем вопросе. — mu is too short

Помимо синтаксической ошибки, это тесно связанный вопрос на dba.SE проливает свет на округление чисел с двойной точностью в PostgreSQL. — Erwin Brandstetter

@muistooshort, спасибо, что указали на это. Там, где написано «среднее», должно быть «круглое». Отредактировано. — user1626730

ради результатов поиска я также получаю эту подсказку в качестве вывода из подсказки: HINT: No function matches the given name and argument types. You might need to add explicit type casts. — Vzzarr

8 ответы

PostgreSQL не определяет round(double precision, integer) . По причинам @Mike Sherrill ‘Cat Recall’ поясняет в комментариях, версия round с точностью доступна только для numeric .

(В вышесказанном обратите внимание, что float8 это просто сокращенный псевдоним для double precision . Вы можете видеть, что PostgreSQL расширяет его в выводе).

Вы должны указать значение, которое нужно округлить до numeric использовать двухаргументную форму round . Просто добавьте ::numeric для сокращенного состава, например round(val::numeric,2) .

Если вы форматируете для отображения пользователю, не используйте round . Используйте to_char (видеть: функции форматирования типов данных в руководстве), который позволяет указать формат и дает text результат, на который не влияют какие-либо странности, которые может сделать ваш клиентский язык numeric значения. Например:

to_char будет округлять числа для вас как часть форматирования. FM префикс сообщает to_char что вы не хотите никаких дополнений с начальными пробелами.

Хм. когда я пробую ROUND(CAST(FLOAT8 ‘3.1415927’ AS NUMERIC),2); , я получаю «0.314E1». И у меня есть код, написанный как ROUND(AVG(val),2) но все равно получаю ошибку, которую я описал в своем вопросе. — user1626730

Я просто сбежал ROUND(CAST(FLOAT8 ‘3.1415927’ AS NUMERIC),2); на PgAdmin и Ruby. С PgAdmin я получаю 3.14, но с Ruby (используя гем Sequel) я получаю «0.314E1». Интересно, почему это. — user1626730

«По какой-то странной причине версия round, которая принимает точность, доступна только для числовых». Числа с плавающей запятой являются «полезными приближениями». Если вы попросите код округлить число с плавающей запятой до двух знаков после запятой, возвращая другой число с плавающей запятой, нет никакой гарантии, что самое близкое приближение к «правильному» ответу будет иметь только две цифры справа от десятичной точки. Числа — это эффективно масштабированные целые числа; у них нет такой проблемы. — Майк Шерилл, « Вспомнить кошку »

@Catcall Хороший вопрос — а double версия round нужно будет вернуться numeric или (тьфу) text , так что это может также занять numeric аргумент. — Крэйг Рингер

Для тех, кто пытается найти комментарий @Catcall: теперь это Майк Шерилл, « Вспомнить кошку » — 18446744073709551615

((это вики! Пожалуйста, отредактируйте, чтобы улучшить!))

Попробуйте также старый синтаксис для приведения,

работает с любой версией PostgreSQL.
. Но, как окончательное решение, вы можете перегрузка функция ОКРУГЛ.

Перегрузка как стратегия приведения

Теперь ваша инструкция будет работать нормально, попробуйте это полное сравнение:

усечение	n_round	f_round	n_тип	f_type	f_round_type
0.666	0.667	0.667	числовой	двойная точность	числовой

Компания ОКРУГЛ(с плавающей запятой,целое число) функция f_round , он возвращает (десятичный) тип данных NUMERIC, который подходит для некоторых приложений: проблема решена!

В других приложениях нам также нужен поплавок. Альтернативой является использование round(f,3)::float или создать round_tofloat() функция. Другая альтернатива, перегрузка ROUND снова функционировать, и используя весь диапазон точность-точность числа с плавающей запятой, должен вернуть число с плавающей запятой, когда точность определена (см. Ответ ЯнКенни),

ПС: команда df round , На psql после перегрузок покажет примерно такую таблицу

в котором плавать является синонимом double precision и myschema is public когда вы не используете схему. pg_catalog функции по умолчанию, см. Руководство по встроенные математические функции.

Округление и форматирование

Компания to_char функция применяется внутри год процедуры, поэтому, когда ваша цель состоит только в том, чтобы показать окончательный результат в терминале, вы можете использовать FM изменение в качестве префикса к шаблону числового формата:

год	усечение	to_char
0.67	0.66	.67

ПРИМЕЧАНИЯ

Причина проблемы

Не хватает перегрузок в некоторых функциях PostgreSQL, почему (. ): я думаю, что «это недостаток» (!), но @CraigRinger, @Catcall и команда PostgreSQL согласны с «историческое обоснование pg».

Примечание о производительности и повторном использовании

Встроенные функции, такие как ROUND из pg_catalog, могут быть перегружены без потери производительности по сравнению с кодированием прямого приведения. При реализации определяемых пользователем функции приведения для высокой производительности:

Компания IMMUTABLE пункт очень важен для таких фрагментов кода, потому что, как сказано в Руководстве: «позволяет оптимизатору предварительно оценить функцию, когда запрос вызывает ее с постоянными аргументами»

PLpgSQL является предпочтительным языком, за исключением «чистого SQL». За JIT-оптимизация (и иногда для параллелизма) language SQL может получить лучшую оптимизацию. Это что-то вроде копирования/вставки небольшого фрагмента кода вместо использования вызова функции.

Вывод: выше ROUND(float,int) функция, после оптимизаций, так быстро, чем Ответ @CraigRinger; он будет скомпилирован (точно) в такое же внутреннее представление. Таким образом, хотя это и не является стандартным для PostgreSQL, оно может быть стандартным для ваших проектов с помощью централизованной и многократно используемой «библиотеки фрагментов», например pg_pubLib.

Округлить до n-го бита или другого числового представления

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

Что ж, давайте решим задачу, добавив экзотическое предложение. Цель здесь — вернуть плавать введите другую перегруженную функцию,
ROUND(float, text, int) RETURNS float
Компания text заключается в том, чтобы предложить выбор между

‘dec’ для «десятичного представления»,
‘bin’ для «бинарного» представления и
‘hex’ для шестнадцатеричного представления.

Итак, в различных представлениях имеем разная интерпретация количества цифр быть округленным. Округление числа x с приблизительно более коротким значением, с меньшим количеством «дробных цифр» (чем его исходное d цифры), будет короче, когда d вычисляет двоичные цифры вместо десятичных или шестнадцатеричных.

Это непросто без C++, используя «чистый SQL», но эти фрагменты кода проиллюстрируют и могут быть использованы в качестве обходного пути:

Источник

Sql error 42883 ошибка функция round double precision integer не существует

Перегрузка как стратегия литья

ERROR: function round(double precision, integer) does not exist #31495

Comments

strk commented Aug 29, 2019

gioman commented Jan 31, 2021

github-actions bot commented Feb 15, 2021

MorriganR commented May 25, 2021

github-actions bot commented Jul 14, 2021

github-actions bot commented Aug 12, 2021

Sql error 42883 ошибка функция round double precision integer не существует

Ответы

Связанные вопросы

Как округлить среднее значение до 2 знаков после запятой в PostgreSQL?

5 ответов:

перегрузка как стратегия кастинга

Sql error 42883 ошибка функция round double precision integer не существует

Как округлить среднее значение до 2 знаков после запятой в PostgreSQL?

8 ответы

Перегрузка как стратегия приведения

Округление и форматирование

ПРИМЕЧАНИЯ

Причина проблемы

Примечание о производительности и повторном использовании

Округлить до n-го бита или другого числового представления

А вот еще интересные материалы: