On 29.10.24 09:47, Peter Eisentraut wrote:
I kind of wonder if we really want to do this. It adds no
functionality, and it forecloses the possibility of changing
the definition later. I understand and agree with your conclusion
that it's pretty much impossible to do what the SQL standard sugges
On Wed, 2024-12-18 at 14:55 -0500, Tom Lane wrote:
> It would not actually be too
> hard I think to build the right regex, if we had the information
> available as to what all the case-variants are. The problem at the
> moment is that the existing code assumes that pg_wc_tolower and
> pg_wc_toupper
Jeff Davis writes:
> On Mon, 2024-12-16 at 17:16 -0500, Tom Lane wrote:
>> The existing logic in the regex engine for case-insensitive matching
>> is to convert every letter to a bracket expression containing all
>> its case variants. For example, "a" becomes "[aA]" and "[xY1]"
>> becomes "[xXyY1
On Mon, 2024-12-16 at 17:16 -0500, Tom Lane wrote:
> Yeah, there is some set of collations for which that would work.
> But I think it requires nontrivial assumptions both about how
> comparison works in the collation, and whether the available
> case-folding logic matches that. An important point
Jeff Davis writes:
> On Tue, 2024-10-22 at 10:40 -0400, Tom Lane wrote:
>> I understand and agree with your conclusion
>> that it's pretty much impossible to do what the SQL standard suggests
>> should happen --- but maybe we're both missing something that would
>> make it feasible.
> It sounds f
On Tue, 2024-10-22 at 10:40 -0400, Tom Lane wrote:
> I understand and agree with your conclusion
> that it's pretty much impossible to do what the SQL standard suggests
> should happen --- but maybe we're both missing something that would
> make it feasible.
It sounds feasible for case-insensitive
On Tue, 2024-10-22 at 10:16 +0200, Peter Eisentraut wrote:
> I also studied the relevant Unicode standard (UTS
> #18) and it makes no mention of collations. So my conclusion is that
> regular expressions should pay no attention to collations. That
> makes
> it easy.
Does normalization play a ro
Peter Eisentraut writes:
> On 22.10.24 16:40, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> In summary, this patch doesn't change any functionality that currently
>>> works. It just removes one error message and lets regular expressions
>>> just run, independent of whether the collation is non
On 22.10.24 16:40, Tom Lane wrote:
Peter Eisentraut writes:
This patch allows using regular expression functions and operators with
nondeterministic collations.
...
In summary, this patch doesn't change any functionality that currently
works. It just removes one error message and lets regular
Peter Eisentraut writes:
> This patch allows using regular expression functions and operators with
> nondeterministic collations.
> ...
> In summary, this patch doesn't change any functionality that currently
> works. It just removes one error message and lets regular expressions
> just run, i
ministic.
From 2c1f47105cdc3a26bb4793cd52516ac30b8f4ec8 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 22 Oct 2024 09:39:23 +0200
Subject: [PATCH v1] Support regular expressions with nondeterministic
collations
For normal regular expressions, the collation doesn't matter, so we
11 matches
Mail list logo
