From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Peter Geoghegan' <pg(at)bowt(dot)ie>, 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Laurenz Albe'" <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | RE: Is it possible to sort strings in EBCDIC order in PostgreSQL server? |
Date: | 2017-12-12 08:17:31 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F84DD45@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Laurenz, Tom, Peter,
Thanks for your suggestions. The practical solution seems to be to override comparison operators of char, varchar and text data types with UDFs that behave as Tom mentioned.
From: Peter Geoghegan [mailto:pg(at)bowt(dot)ie]
> That said, the idea of an "EBCDIC collation" seems limiting. Why
> should a system like DB2 for the mainframe (that happens to use EBCDIC
> as its encoding) not have a more natural, human-orientated collation
> even while using EBCDIC? ISTM that the point of using the "C" locale
> (with EBDIC or with UTF-8 or with any other encoding) is to get a
> performance benefit where the actual collation's behavior doesn't
> matter much to users. Are you sure it's really important to be
> *exactly* compatible with EBCDIC order? As long as you're paying for a
> custom collation, why not just use a collation that is helpful to
> humans?
You are right. I'd like to ask the customer whether and why they need EBCDIC ordering.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Yogesh Sharma | 2017-12-12 09:52:03 | Size of pg_multixact/members increases 11355 |
Previous Message | Jim Finnerty | 2017-12-12 03:56:04 | Re: Why the planner does not use index for a large amount of data? |