Re: Upgrading pg_statistic to handle collation honestly - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Upgrading pg_statistic to handle collation honestly
Date
Msg-id 106ec7b1-83c4-4fba-f10a-d0213fe19694@2ndquadrant.com
Whole thread Raw
In response to Upgrading pg_statistic to handle collation honestly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Upgrading pg_statistic to handle collation honestly
List pgsql-hackers
On 12/12/2018 16:57, Tom Lane wrote:
> diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
> index b8445dc..dcbd04c 100644
> *** a/src/backend/commands/analyze.c
> --- b/src/backend/commands/analyze.c
> *************** examine_attribute(Relation onerel, int a
> *** 904,914 ****
> --- 904,917 ----
>       {
>           stats->attrtypid = exprType(index_expr);
>           stats->attrtypmod = exprTypmod(index_expr);
> +         stats->attrcollid = exprCollation(index_expr);
> +         /* XXX should we consult indcollation instead? */

After looking through this again, I think the answer here is "yes".  If
the index definition overrides the collation, then we clearly want to
use that.  If it's not overridden, then indcollation is still set, so
it's just as easy to use it.

>       }
>       else
>       {
>           stats->attrtypid = attr->atttypid;
>           stats->attrtypmod = attr->atttypmod;
> +         stats->attrcollid = attr->attcollation;
>       }
>   
>       typtuple = SearchSysCacheCopy1(TYPEOID,


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


pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: ALTER INDEX ... ALTER COLUMN not present in dump
Next
From: Laurenz Albe
Date:
Subject: Re: Where to save data used by extension ?