Re: BUG #18568: BUG: Result wrong when do group by on partition table!
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Tender Wang <tndrwang@gmail.com>
Cc: 1105066510@qq.com, pgsql-bugs@lists.postgresql.org
Date: 2024-10-22T09:25:41Z
Lists: pgsql-bugs
On Tue, Oct 22, 2024 at 5:30 PM Tender Wang <tndrwang@gmail.com> wrote: > Amit Langote <amitlangote09@gmail.com> 于2024年10月22日周二 15:33写道: >> Not really. As the documentation says, collation can be specified per >> column or per operation: >> >> https://www.postgresql.org/docs/current/collation.html >> >> In this case, the operation is partitioning. When you specify the >> COLLATE clause for a partition key, it means that the partitioning >> logic, such as partition tuple routing, will use that collation >> instead of the column-specified or the column type's collation. > > > Since you said partition key had its own collation, and but we used column type's collation in > set_baserel_partition_key_exprs() as below: > > partexpr = (Expr *) makeVar(varno, attno, > partkey->parttypid[cnt], > partkey->parttypmod[cnt], > partkey->parttypcoll[cnt], 0); > > I think why not we directly use the partition key collation(e.g. partcollation). That's a good question but I don't immediately know the answer. It seems like it has been like this since the beginning or since the commit that added the RelOptInfo.partexprs field (9140cf8269). -- Thanks, Amit Langote
Commits
-
Disallow partitionwise grouping when collations don't match
- 90fe6251c816 18.0 landed
- b6484ca9535e 17.1 landed
- dd2f8ebee221 16.5 landed
- 0a620659c549 15.9 landed
- 96f9b29a3e1e 14.14 landed
- ff65f695c0d3 13.17 landed
- 46d9be5efb1a 12.21 landed
-
For partitionwise join, match on partcollation, not parttypcoll.
- 2af28e603319 11.0 cited