Re: pg_dump losing index column collations for unique and primary keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexey Bashtanov <bashtanov(at)imap(dot)cc>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_dump losing index column collations for unique and primary keys
Date: 2019-12-03 16:57:57
Message-ID: 13713.1575392277@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexey Bashtanov <bashtanov(at)imap(dot)cc> writes:
> I found that pg_dump fails to note down the collations used primary and
> unique keys supporting indexes.
> To reproduce:

> create table f(a text);
> create unique index f_pkey on f(a collate "C.UTF-8");
> alter table f add primary key using index f_pkey;

Hm. I kinda think that we should reject the above. The point of
ADD PRIMARY KEY USING INDEX ought to be to allow you to build
the index concurrently; it should not be something you can use to
create a DDL state that is impossible to arrive at with plain
ADD PRIMARY KEY.

As an example of the sort of problem that I'm worried about,
consider a situation where the index's collation has a different
notion of equality than the column's default collation has.
(Which is entirely possible now that we have nondeterministic
collations.) That's going to lead to weird restrictions on
whether the index really satisfies query WHERE conditions, and
I'd bet considerable money that we'd have bugs due to failing
to account for that.

In short, I'd say the bug here is not pg_dump's fault at all,
but failure to insist on collation match in ADD PRIMARY KEY
USING INDEX.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Raymond 2019-12-03 17:00:42 RE: BUG #16145: Not able to terminate active session
Previous Message Tomas Vondra 2019-12-03 16:38:18 Re: BUG #16145: Not able to terminate active session