Re: Upgrading pg_statistic to handle collation honestly

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Upgrading pg_statistic to handle collation honestly
Date: 2018-12-14 08:24:50
Message-ID: 106ec7b1-83c4-4fba-f10a-d0213fe19694@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2018-12-14 08:25:07 Re: Where to save data used by extension ?
Previous Message Amul Sul 2018-12-14 08:08:45 Re: ALTER INDEX ... ALTER COLUMN not present in dump