mirror of
https://github.com/postgres/postgres.git
synced 2026-06-25 08:29:05 -04:00
0e1f1ed157
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.com
Backpatch-through: 14
|
||
|---|---|---|
| .. | ||
| data | ||
| expected | ||
| sql | ||
| .gitignore | ||
| Makefile | ||
| meson.build | ||
| seg--1.0--1.1.sql | ||
| seg--1.1--1.2.sql | ||
| seg--1.1.sql | ||
| seg--1.2--1.3.sql | ||
| seg--1.3--1.4.sql | ||
| seg-validate.pl | ||
| seg.c | ||
| seg.control | ||
| segdata.h | ||
| segparse.y | ||
| segscan.l | ||
| sort-segments.pl | ||