e next one is inconsistent.
From 34f5bb1e8f0ffbb39b1efc936f6b4d6c4caa Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 28 Jun 2024 06:55:45 +0200
Subject: [PATCH v2] Support LIKE with nondeterministic collations
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Enco
On 03.05.24 17:47, Daniel Verite wrote:
Peter Eisentraut wrote:
However, off the top of my head, this definition has three flaws: (1)
It would make the single-character wildcard effectively an
any-number-of-characters wildcard, but only in some circumstances, which
could be
On 03.05.24 16:58, Daniel Verite wrote:
* Generating bounds for a sort key (prefix matching)
Having sort keys for strings allows for easy creation of bounds -
sort keys that are guaranteed to be smaller or larger than any sort
key from a give range. For example, if bounds are
Peter Eisentraut wrote:
> However, off the top of my head, this definition has three flaws: (1)
> It would make the single-character wildcard effectively an
> any-number-of-characters wildcard, but only in some circumstances, which
> could be confusing, (2) it would be difficult to
Peter Eisentraut wrote:
> Yes, certainly, and there is also no indexing support (other than for
> exact matches).
The ICU docs have this note about prefix matching:
https://unicode-org.github.io/icu/userguide/collation/architecture.html#generating-bounds-for-a-sort-key-prefix-matching
On 03.05.24 15:20, Robert Haas wrote:
On Fri, May 3, 2024 at 4:52 AM Peter Eisentraut wrote:
What the implementation does is, it walks through the pattern. It sees
'_', so it steps over one character in the input string, which is '.'
here. Then we have 'foo.' left to match in the input
On Fri, May 3, 2024 at 4:52 AM Peter Eisentraut wrote:
> What the implementation does is, it walks through the pattern. It sees
> '_', so it steps over one character in the input string, which is '.'
> here. Then we have 'foo.' left to match in the input string. Then it
> takes from the
On 03.05.24 02:11, Robert Haas wrote:
On Thu, May 2, 2024 at 9:38 AM Peter Eisentraut wrote:
On 30.04.24 14:39, Daniel Verite wrote:
postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct;
?column?
--
f
(1 row)
The first two results look fine, but the next one
On Thu, May 2, 2024 at 9:38 AM Peter Eisentraut wrote:
> On 30.04.24 14:39, Daniel Verite wrote:
> >postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct;
> > ?column?
> >--
> > f
> >(1 row)
> >
> > The first two results look fine, but the next one is inconsistent.
>
On 30.04.24 14:39, Daniel Verite wrote:
postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct;
?column?
--
f
(1 row)
The first two results look fine, but the next one is inconsistent.
This is correct, because '_' means "any single character". This is
independent of
Peter Eisentraut wrote:
> This patch adds support for using LIKE with nondeterministic
> collations. So you can do things such as
>
> col LIKE 'foo%' COLLATE case_insensitive
Nice!
> The pattern is partitioned into substrings at wildcard characters
> (so 'foo%bar' is partitioned
tring.From 3f6b584a0f34cabecac69f3cfd663dadfd34f464 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 29 Apr 2024 07:58:20 +0200
Subject: [PATCH v1] Support LIKE with nondeterministic collations
This allows for example using LIKE with case-insensitive collations.
There was previously n
12 matches
Mail list logo
