Re: Use correct collation in pg_trgm

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

In response to

Responses

Browse pgsql-hackers by date

  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