Re: Built-in CTYPE provider

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Noah Misch <noah(at)leadboat(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Jeremy Schneider <schneider(at)ardentperf(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Built-in CTYPE provider
Date: 2024-07-18 08:05:34
Message-ID: 4efae9f992f96a1e8eba0f515c637c3ff252d0fc.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2024-07-17 at 15:03 -0700, Noah Misch wrote:
> If I'm counting the votes right, you and Tom have voted that the feature's
> current state is okay, and I and Laurenz have voted that it's not okay.

Maybe I should expand my position.

I am very much for the built-in CTYPE provider. When I said that I am against
changes in major versions, I mean changes that are likely to affect real-life
usage patterns. If there are modifications affecting a code point that was
previously unassigned, it is *theoretically* possible, but very unlikely, that
someone has stored it in a database. I would want to deliberate about any change
affecting such a code point, and if the change seems highly desirable, we can
consider applying it.

What I am against is routinely updating the built-in provider to adopt any changes
that Unicode makes.

To make a comparison with Tom's argument upthread: we have slightly changed how
floating point computations work, even though they are IMMUTABLE. But I'd argue
that very few people build indexes on the results of floating point arithmetic
(and those who do are probably doing something wrong), so the risk is acceptable.
But people index strings all the time.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2024-07-18 08:11:50 Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Previous Message Alexander Lakhin 2024-07-18 08:00:00 Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()