Message-ID: <3da3dcc06220f80537dc1fb2c32cb76c91f87b93.camel@cybertec.at>
Subject: Re: Explanation of the ROUND function with NUMERIC as an argument
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: kamiya33hirokazu@gmail.com, pgsql-docs@lists.postgresql.org
Date: Sat, 03 Dec 2022 14:34:56 +0100
In-Reply-To: <167005767233.1899.2490889277144246641@wrigleys.postgresql.org>
References: <167005767233.1899.2490889277144246641@wrigleys.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/3da3dcc06220f80537dc1fb2c32cb76c91f87b93.camel%40cybertec.at>
Precedence: bulk

On Sat, 2022-12-03 at 08:54 +0000, PG Doc comments form wrote:
> Explanation of the manual's ROUND function
> round ( numeric ) → numeric
> round ( double precision ) → double precision
> Rounds to nearest integer. For numeric, ties are broken by rounding away
> from zero. For double precision, the tie-breaking behavior is platform
> dependent, but “round to nearest even” is the most common rule.
> round(42.4) → 42
> 
> Operation of the ROUND function
> postgres=# SELECT round(CAST(42.5 AS numeric));
>  round
> -------
>     43
> (1 row)
> 
> I am thinking that the value of the ROUND function with NUMERIC as an
> argument is rounded off, not rounded away from zero.

It is rounded away from zero, since 43 is farther away from 0 than 42.5.
This may be a language problem.

Yours,
Laurenz Albe