Peter Eisentraut writes:
> On 12/12/2018 16:57, Tom Lane wrote:
>> +stats->attrcollid = exprCollation(index_expr);
>> +/* XXX should we consult indcollation instead? */
> After looking through this again, I think the answer here is "yes".
Yeah, I was leaning towards that
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
Peter Eisentraut writes:
> On 12/12/2018 16:57, Tom Lane wrote:
>> * Probably this conflicts to some extent with Peter's "Reorganize
>> collation lookup" patch, but I haven't studied that yet.
> I've looked it over, and it's nothing that can't be easily fixed up. In
> fact, it simplifies a few t
On 12/12/2018 16:57, Tom Lane wrote:
> Attached is a draft patch for same. It adds storage to pg_statistic
> to record the collation of each statistics "slot". A plausible
> alternative design would be to just say "look at the collation of the
> underlying column", but that would require extra ca
When we first put in collations support, we basically punted on teaching
ANALYZE, pg_statistic, and the planner selectivity functions about that.
They just use DEFAULT_COLLATION_OID independently of the actual collation
of the data. I tripped over this while investigating making type "name"
collat
