Rounding strategy
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t76975psql -h localhost -U postgresBuilt from patchset v5 (message #5), August 18, 2026 at 04:05 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t76975_5 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t76975_5 && git checkout t76975_5Patchset v5 (message #5) is on t76975_5
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/functions-math.html
Description:
The 'round' mathematical function documentation doesn't specify its rounding
strategy. If this would be documented then users can rely on its rounding
behavior. For double precision the rounding probably depends on your
platform. For numeric the function seems to round to nearest with ties going
away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and
-6.5 -> -7.0.
On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/functions-math.html
Description:The 'round' mathematical function documentation doesn't specify its rounding
strategy. If this would be documented then users can rely on its rounding
behavior. For double precision the rounding probably depends on your
platform. For numeric the function seems to round to nearest with ties going
away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and
-6.5 -> -7.0.
+1
Yours,
Laurenz Albe
On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote:
The 'round' mathematical function documentation doesn't specify its rounding
strategy. If this would be documented then users can rely on its rounding
behavior. For double precision the rounding probably depends on your
platform. For numeric the function seems to round to nearest with ties going
away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and
-6.5 -> -7.0.
Here is a proposed patch.
Yours,
Laurenz Albe
Attachments:
0001-Document-tie-breaking-behavior-of-round.patchtext/x-patch; charset=UTF-8; name=0001-Document-tie-breaking-behavior-of-round.patchDownload+4-3
Laurenz Albe <laurenz.albe@cybertec.at> writes:
On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote:
The 'round' mathematical function documentation doesn't specify its rounding
strategy. If this would be documented then users can rely on its rounding
behavior. For double precision the rounding probably depends on your
platform. For numeric the function seems to round to nearest with ties going
away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and
-6.5 -> -7.0.
Here is a proposed patch.
LGTM, although I think we can be a bit more specific about the float
case. I suggest
... by rounding away from 0. For <type>double precision</type>,
the tie-breaking behavior is platform dependent, but
<quote>round to nearest even</quote> is the most common rule.
regards, tom lane
On Thu, 2021-04-22 at 13:50 -0400, Tom Lane wrote:
Laurenz Albe <laurenz.albe@cybertec.at> writes:
On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote:
The 'round' mathematical function documentation doesn't specify its rounding
strategy. If this would be documented then users can rely on its rounding
behavior. For double precision the rounding probably depends on your
platform. For numeric the function seems to round to nearest with ties going
away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and
-6.5 -> -7.0.Here is a proposed patch.
LGTM, although I think we can be a bit more specific about the float
case. I suggest... by rounding away from 0. For <type>double precision</type>,
the tie-breaking behavior is platform dependent, but
<quote>round to nearest even</quote> is the most common rule.
Makes sense. Here is an updated patch.
Yours,
Laurenz Albe
On Fri, 2021-04-23 at 09:40 +0200, Laurenz Albe wrote:
Makes sense. Here is an updated patch.
I see that you have already committed your proposed version.
Thanks!
Yours,
Laurenz Albe
