agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedpgsql: Fix integer to_char() overflow with V format
7+ messages / 1 participants
[nested] [flat]
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:44 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:44 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/3b120b1e94dd0387ca40e1e356f6b7eb8793d297
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:44 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:44 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/9efc2f9d8964ec927ccdeb4d461ff8070b0e6255
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:44 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:44 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/ec434db1f49d015150cbedfe16fdf7c6456fa8d5
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:44 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:44 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/04c25af21c02bf2c5152c3c8ab2ba877c231a598
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:44 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:44 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/55af98a45aef2ed1495c6813c9d1c8ee89df3607
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:45 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:45 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/772251744a505e2a28e7c2daf2f5be33a748295a
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix integer to_char() overflow with V format
@ 2026-09-01 02:45 Fujii Masao <fujii@postgresql.org>
0 siblings, 0 replies; 7+ messages in thread
From: Fujii Masao @ 2026-09-01 02:45 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix integer to_char() overflow with V format
When to_char() formatted an integer value with a V pattern, it could
return an incorrect result instead of reporting an overflow. V shifts
the decimal point by multiplying the input value by a power of ten before
formatting it, so, for example,
to_char(3, '9V999999999')
requires computing 3 * 10^9. This result does not fit in int4, but
the integer variant of to_char() performed the multiplication using a
plain int32 expression. The intermediate result could therefore
overflow, causing the function to output incorrect digits instead of
raising "integer out of range".
Use dtoi4() and int4mul() for this calculation so that both an
out-of-range multiplier and an out-of-range product are detected, as
with ordinary integer arithmetic. This also matches the existing int8
implementation, which uses dtoi8() and int8mul() for the same
operation.
After this change, to_char() with V format either returns the
correctly formatted result when the scaled value fits in int4, or
raises "integer out of range" when it does not.
Backpatch to all supported versions.
Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Author: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com
Backpatch-through: 14
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f1c6f7ec95dc0434726738a5733491ef00a5a640
Modified Files
--------------
src/backend/utils/adt/formatting.c | 16 +++++++++-------
src/test/regress/expected/int4.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/int4.sql | 9 +++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-09-01 02:45 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-01 02:44 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
2026-09-01 02:44 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
2026-09-01 02:44 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
2026-09-01 02:44 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
2026-09-01 02:44 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
2026-09-01 02:45 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
2026-09-01 02:45 pgsql: Fix integer to_char() overflow with V format Fujii Masao <fujii@postgresql.org>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox