agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedpgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
6+ messages / 1 participants
[nested] [flat]
* pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
@ 2026-06-11 09:43 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-06-11 09:43 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail...
Backpatch-through: 14
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/0004cab4dc60577779d97a8f1a175b6dd07dc223
Modified Files
--------------
contrib/seg/expected/seg.out | 45 +++++++++++++++++++++++++++++++++++++++++++-
contrib/seg/seg.c | 2 +-
contrib/seg/sql/seg.sql | 11 ++++++++++-
3 files changed, 55 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
@ 2026-06-11 09:43 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-06-11 09:43 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail...
Backpatch-through: 14
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/bcbbd070d4961aa4c2f983bdbcf488c0c0d752a1
Modified Files
--------------
contrib/seg/expected/seg.out | 45 +++++++++++++++++++++++++++++++++++++++++++-
contrib/seg/seg.c | 2 +-
contrib/seg/sql/seg.sql | 11 ++++++++++-
3 files changed, 55 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
@ 2026-06-11 09:43 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-06-11 09:43 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail...
Backpatch-through: 14
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/504ca05133db7afab7351ddc3be72e5eb614ed7e
Modified Files
--------------
contrib/seg/expected/seg.out | 45 +++++++++++++++++++++++++++++++++++++++++++-
contrib/seg/seg.c | 2 +-
contrib/seg/sql/seg.sql | 11 ++++++++++-
3 files changed, 55 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
@ 2026-06-11 09:43 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-06-11 09:43 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail...
Backpatch-through: 14
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/b3aa2083a4dabdcfa4b240f956c49784ec0fb34d
Modified Files
--------------
contrib/seg/expected/seg.out | 45 +++++++++++++++++++++++++++++++++++++++++++-
contrib/seg/seg.c | 2 +-
contrib/seg/sql/seg.sql | 11 ++++++++++-
3 files changed, 55 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
@ 2026-06-11 09:43 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-06-11 09:43 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail...
Backpatch-through: 14
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/58b91fc73a8679a78e7dc1430169a555ee5c8a81
Modified Files
--------------
contrib/seg/expected/seg.out | 45 +++++++++++++++++++++++++++++++++++++++++++-
contrib/seg/seg.c | 2 +-
contrib/seg/sql/seg.sql | 11 ++++++++++-
3 files changed, 55 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in
@ 2026-06-11 09:43 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-06-11 09:43 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
seg: Fix seg_out() to preserve the upper boundary's certainty indicator
When printing the upper boundary of a seg interval, seg_out() decided
whether to emit the certainty indicator ('<', '>' or '~') by testing the
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower
indicator (l_ext) for '~'. This is a copy-and-paste slip from the
symmetric code that prints the lower boundary a few lines above.
The consequences for valid input were:
* A '~' on the upper boundary was dropped on output, e.g.
'1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.
* When the lower boundary carried '~' but the upper boundary had no
indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)
wrote a NUL byte (u_ext == '\0'), which truncated the result string
and silently lost the entire upper boundary, e.g.
'~6.5 .. 8.5'::seg printed as '~6.5 .. '.
Certainty indicators are documented to be preserved on output (they are
ignored by the operators, but kept as comments), so this broke the
input/output round-trip for the affected values.
The bug has existed since seg was added. It went unnoticed because the
existing regression tests only exercised certainty indicators on
single-point segs, which are printed by a different branch of seg_out().
Add tests that place indicators on both boundaries of an interval.
Author: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail...
Backpatch-through: 14
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/0e1f1ed157e90741e12a3715909e1b2d71ff9344
Modified Files
--------------
contrib/seg/expected/seg.out | 45 +++++++++++++++++++++++++++++++++++++++++++-
contrib/seg/seg.c | 2 +-
contrib/seg/sql/seg.sql | 11 ++++++++++-
3 files changed, 55 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-06-11 09:43 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-11 09:43 pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-06-11 09:43 pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-06-11 09:43 pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-06-11 09:43 pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-06-11 09:43 pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-06-11 09:43 pgsql: seg: Fix seg_out() to preserve the upper boundary's certainty in Heikki Linnakangas <heikki.linnakangas@iki.fi>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox