Re: pg_dump losing index column collations for unique and primary keys
От | Tom Lane |
---|---|
Тема | Re: pg_dump losing index column collations for unique and primary keys |
Дата | |
Msg-id | 13713.1575392277@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_dump losing index column collations for unique and primary keys (Alexey Bashtanov <bashtanov@imap.cc>) |
Ответы |
Re: pg_dump losing index column collations for unique and primary keys
|
Список | pgsql-bugs |
Alexey Bashtanov <bashtanov@imap.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
В списке pgsql-bugs по дате отправления: