Re: EBCDIC sorting as a use case for ICU rules - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: EBCDIC sorting as a use case for ICU rules
Date
Msg-id 43f985553257c3b8b77467515c108948d72c1a9e.camel@j-davis.com
Whole thread Raw
In response to EBCDIC sorting as a use case for ICU rules  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: EBCDIC sorting as a use case for ICU rules
Re: EBCDIC sorting as a use case for ICU rules
List pgsql-hackers
On Wed, 2023-06-21 at 15:28 +0200, Daniel Verite wrote:
> At a conference this week I was asked if ICU could be able to
> sort like EBCDIC [2]. It turns out it has been already  asked on
> -general a few years ago [3] with no satisfactory answer at the time
> ,
> and that it can be implemented with rules in v16.

Interesting, thank you!

> This can be useful for people who migrate from mainframes to Postgres
> and need their migration tests to produce the same sorted results as
> the
> original system.
> Since rules can be defined at the database level with the icu_rules
> option,
> they don't even need to tweak their queries to add COLLATE clauses,
> which surely is appreciable in that kind of project.

I still had some technical concerns about the ICU rules feature,
unfortunately, and one option is to only allow it for the collation
objects and not the database level collation. How much would that hurt
this use case?


> I'm open to suggestions on whether this EBCDIC example is worth being
> in the
> doc in some form or putting this in the wiki would be good enough.

I like the idea of having a real example. Ideally, we could add some
explanation along the way about how the rule is constructed to match
EBCDIC, which would reduce the shock of a long rule like that.

I wonder why the rule syntax is such that it cannot be broken up? Would
it be incorrect for us to allow some whitespace in there?

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: bgwriter doesn't flush WAL stats
Next
From: James Coleman
Date:
Subject: Re: Use of additional index columns in rows filtering