Re: Collation versioning - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Collation versioning
Date
Msg-id 13b0c950-80f9-4c10-7e0f-f59feac56a98@2ndquadrant.com
Whole thread Raw
In response to Re: Collation versioning  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Collation versioning
List pgsql-hackers
On 2020-07-08 08:26, Michael Paquier wrote:
> On Wed, Jul 08, 2020 at 06:12:51PM +1200, Thomas Munro wrote:
>> I still wish I had a better idea than this:
>>
>> +/*
>> + * Returns whether the given index access method depend on a stable collation
>> + * order.
>> + */
>> +static bool
>> +index_depends_stable_coll_order(Oid amoid)
>> +{
>> +       return (amoid != HASH_AM_OID &&
>> +                       strcmp(get_am_name(amoid), "bloom") != 0);
>> +}
>>
>> I'm doing some more testing and looking for weird cases...  More soon.
> 
> Wouldn't the normal way to track that a new field in IndexAmRoutine?
> What you have here is not extensible.

Yeah, this should be decided and communicated by the index AM somehow.

Perhaps it would also make sense to let the index AM handle the 
differences between deterministic and nondeterministic collations.  I 
don't know how the bloom AM works, though, to determine whether that 
makes sense.

In order not to derail this patch set I think it would be okay for now 
to just include all index AMs in dependency tracking and invent a 
mechanism later that excludes hash and bloom in an extensible manner.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Stale external URL in doc?
Next
From: "kato-sho@fujitsu.com"
Date:
Subject: RE: Performing partition pruning using row value