Re: Upgrading pg_statistic to handle collation honestly
От | Peter Eisentraut |
---|---|
Тема | Re: Upgrading pg_statistic to handle collation honestly |
Дата | |
Msg-id | 106ec7b1-83c4-4fba-f10a-d0213fe19694@2ndquadrant.com обсуждение исходный текст |
Ответ на | Upgrading pg_statistic to handle collation honestly (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Upgrading pg_statistic to handle collation honestly
|
Список | 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 по дате отправления: