From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | [3반]김민지_4904 <hzuiw33(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Sorting Discrepancy in PostgreSQL 14.13 |
Date: | 2024-11-15 04:25:34 |
Message-ID: | 2358737.1731644734@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tomas Vondra <tomas(at)vondra(dot)me> writes:
> On 11/14/24 13:49, [3반]김민지_4904 wrote:
>> I'm doubtful this is a collation issue, as most collations basically
>> respect ASCII order.
> This is 99.999% due to the collation, so which collations are being used
> on these systems? Also, I don't get this "incorrect" behavior on 14.13,
> it behaves the same as 17 for me, producing the expected result.
It surely is a collation issue. Using a glibc-based system, I get
u8=# CREATE TABLE t0 (c0 TEXT);
CREATE TABLE
u8=# INSERT INTO t0 (c0) VALUES ('-10'), ('20'), ('-5'), ('15'), ('-25');
INSERT 0 5
u8=# select * from t0 order by c0 collate "C";
c0
-----
-10
-25
-5
15
20
(5 rows)
u8=# select * from t0 order by c0 collate "en_US";
c0
-----
-10
15
20
-25
-5
(5 rows)
(In point of fact, most glibc collations do NOT "respect ASCII order".
They tend to ignore punctuation until it's needed as a tiebreaker.)
So this is surely down to the PG 14.13 installation having a different
default collation than whatever it's compared to, which most likely
is caused by having run initdb with a different locale environment.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tender Wang | 2024-11-15 06:17:05 | Re: BUG #18705: Segmentation fault when create brin index on user-defined type. |
Previous Message | PG Bug reporting form | 2024-11-15 02:50:47 | BUG #18710: "pg_get_viewdef" triggers assertions in special scenarios |