| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | David Geier <geidav(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Use correct collation in pg_trgm |
| Date: | 2026-03-26 18:12:14 |
| Message-ID: | 677b2db1582d9eb9e099ea83856e610a5072dcd3.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2026-03-26 at 09:50 +0100, David Geier wrote:
> I agree. That is inconsistent. But if anything, shouldn't we change
> tsvector/tsquery to as well adhere to the inferred collation?
I am not sure either way.
It's easy to specify a COLLATE clause to affect the interpretation of
the input. But once you parse the inputs into a stored value, you can't
later reinterpret those values by specifying a COLLATE clause. The
parsing already happened and the original input string was lost.
You can end up with a table full of values, some of which were parsed
with one set of semantics, and others parsed with a different set of
semantics. That may make sense or it may just cause confusion. It's
tough for me to say.
Another consequence is that if we actually declare a type to be
collatable, then parsing will infer the collation all the way through.
Is that what we want?
In any case, I think we should make an explicit decision about which
way to go before making changes. Including Peter, who probably has an
opinion here.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-26 18:14:03 | Re: DOCS - Add introductory paragraph to Getting Started chapter |
| Previous Message | Jim Jones | 2026-03-26 18:12:04 | Re: COMMENTS are not being copied in CREATE TABLE LIKE |