On Wed, Aug 6, 2025 at 9:21 PM Jeff Davis wrote:
> > Yes, I was not in favor of backpatching this, since it was not a bug
> > fix. And it turns out it was incomplete. I think we should revert
> > all
> > the backpatches and iterate on getting the documentation the way we
> > want
> > in master.
On Wed, 2025-08-06 at 13:44 +0200, Peter Eisentraut wrote:
> It's meant to be an Oracle-compatible function, so maybe someone can
> check there for some details.
If it's purely a compatibility function, then using ICU's sophisticated
word break iterator doesn't make sense.
> https://docs.oracle.
On Wed, Aug 6, 2025 at 2:44 PM Peter Eisentraut wrote:
>
> On 04.08.25 22:59, Jeff Davis wrote:
> > On Mon, 2025-08-04 at 12:30 +0700, Oleg Tselebrovskiy wrote:
> >> First patch just adds this warning about not relying on initcap()
> >> exact
> >> result. The second one is the same, but removes th
On 04.08.25 22:59, Jeff Davis wrote:
On Mon, 2025-08-04 at 12:30 +0700, Oleg Tselebrovskiy wrote:
First patch just adds this warning about not relying on initcap()
exact
result. The second one is the same, but removes the part "what is a
word"
since it's could be moot because we recommend writin
Jeff Davis wrote at 2025-08-05 03:59:
One more thing: we should also change it to "... to upper case (or
title case) and the rest to lower case...". Title case is for scripts
that have characters like 'Dž' (U+01C5).
Done based upon second version of previous patch. Again, there are two
versions
On Mon, 2025-08-04 at 12:30 +0700, Oleg Tselebrovskiy wrote:
> First patch just adds this warning about not relying on initcap()
> exact
> result. The second one is the same, but removes the part "what is a
> word"
> since it's could be moot because we recommend writing custom
> functions,
> so un
Jeff Davis wrote at 2025-07-31 02:58:
Apologies for the late answer to a review
First, it doesn't mention the "builtin" provider, which uses the same
word break rules as libc.
Completely forgot about builtin provider in the first patch, my bad
Second, word boundaries can be complex, and I'm
On Mon, 2025-07-28 at 13:20 +0300, Alexander Korotkov wrote:
> I can confirm inicap works with libc and libicu as you stated. The
> documentation patch looks good to me. I’ve written a commit message.
> The REL_12_STABLE branch is not relevant anymore as it’s out of
> support. I’m going to push
Alexander Korotkov wrote at 2025-07-28 17:23:
On Mon, Jul 28, 2025 at 1:20 PM Alexander Korotkov
wrote:
On 25 Sep 2024, at 18:13, Oleg Tselebrovskiy
wrote:
Greetings, everyone!
One of our clients has found a difference in behaviour of initcap
function when
using different locale provide
On Mon, Jul 28, 2025 at 1:20 PM Alexander Korotkov wrote:
>
> On 25 Sep 2024, at 18:13, Oleg Tselebrovskiy
> wrote:
>
> Greetings, everyone!
>
> One of our clients has found a difference in behaviour of initcap function
> when
> using different locale providers, shown below
>
> postgres=# creat
Hi, Oleg!On 25 Sep 2024, at 18:13, Oleg Tselebrovskiy wrote:Greetings, everyone!One of our clients has found a difference in behaviour of initcap function whenusing different locale providers, shown below postgres=# create database test_db_1 locale_provider=icu locale="ru_RU.UTF-8" template=templa
Greetings, everyone!
One of our clients has found a difference in behaviour of initcap
function when
using different locale providers, shown below
postgres=# create database test_db_1 locale_provider=icu
locale="ru_RU.UTF-8" template=template0;
NOTICE: using standard form "ru-RU" f
12 matches
Mail list logo
