| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [19] Proposal: function markers to indicate collation/ctype sensitivity |
| Date: | 2025-06-05 20:57:15 |
| Message-ID: | 4f1fb76892db1dc7ca408d6f27aa159f63cbf81c.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
However, even in that case, I'm not sure if it's worth keeping track of
a separate marker.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-06-05 21:07:44 | Re: track generic and custom plans in pg_stat_statements |
| Previous Message | Ilia Evdokimov | 2025-06-05 20:52:45 | Re: track generic and custom plans in pg_stat_statements |