From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [19] Proposal: function markers to indicate collation/ctype sensitivity |
Date: | 2025-06-11 06:55:30 |
Message-ID: | 64993306-d23b-4634-9a37-e417f5c5d256@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05.06.25 22:57, Jeff Davis wrote:
> On Tue, 2025-06-03 at 20:22 -0700, Jeff Davis wrote:
>> EQUALITY marker: indicates that the function or index AM depends on
>> CollOid for the equality semantics of the input expression. Examples:
>> texteq(), btree AM, hash AM. (Note: EQUALITY is only important for
>> non-
>> deterministic collations and we might want to omit it if too many
>> functions qualify, but it helps illustrate the rest of the proposal
>> so
>> I will leave it in for now.)
>
> I had trouble contriving a case where tracking EQUALITY as a separate
> marker would be practically useful. When we allow non-deterministic
> collations at the database level in the future, it might be useful in a
> case like:
>
> CREATE TABLE r(t TEXT, CHECK(length(t) <= 10));
>
> because length() doesn't care about equality, so it would have no
> dependency on the database collation even if it were, for example,
> case-insensitive.
But such a length() function would also not care about the "collate" or
"ctype" markers. So it would probably not be marked at all.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-06-11 07:03:46 | Re: [19] Proposal: function markers to indicate collation/ctype sensitivity |
Previous Message | John Naylor | 2025-06-11 06:48:57 | Re: [V2] Adding new CRC32C implementation for IBM S390X |