Re: hashing bpchar for nondeterministic collations is broken

On Thu, 2022-12-01 at 12:11 -0800, Jeff Davis wrote:
> I don't see any major consequences

Yikes, it looks like this is a problem for BPCHAR (without typmod
specified):

create table p_bpchar(t bpchar collate ctest_nondet, i int)
partition by hash(t);
create table p0_bpchar partition of p_bpchar
for values with (modulus 4, remainder 0);
create table p1_bpchar partition of p_bpchar
for values with (modulus 4, remainder 1);
create table p2_bpchar partition of p_bpchar
for values with (modulus 4, remainder 2);
create table p3_bpchar partition of p_bpchar
for values with (modulus 4, remainder 3);

insert into p_bpchar values
('a', 0),
('a ', 1),
('a ', 2),
('a ', 3),
('a ', 4),
('a ', 5),
('a ', 6),
('a ', 7);

select count(*) from p0_bpchar; -- 2
select count(*) from p1_bpchar; -- 2
select count(*) from p2_bpchar; -- 3
select count(*) from p3_bpchar; -- 1

It seems like CHAR is not a problem, even though BPCHAR is documented
as an alias, because the planner treats BPCHAR->CHAR as a length
coercion, which trims trailing spaces.

And we just documented BPCHAR in v16 (0937f6d172), so the problem is
about to be worse. I suppose as of v15 we could argue that BPCHAR is
just an internal detail and that people shouldn't be creating columns
of that type?

--
Jeff Davis
PostgreSQL Contributor Team - AWS