Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
От | Tom Lane |
---|---|
Тема | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |
Дата | |
Msg-id | 3371540.1671119678@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' (Vik Fearing <vik@postgresfriends.org>) |
Ответы |
Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |
Список | pgsql-bugs |
Vik Fearing <vik@postgresfriends.org> writes: > If the point in adding a primary key USING INDEX is to avoid building an > index, then this restriction defeats that purpose. We have no ALTER > INDEX command to switch or drop the <unique null treatment>. Well, if you want to build an index to then use as a primary key, it's incumbent on you to make the index with the correct properties. Do you expect the system to silently fix it for you if the index is on the wrong columns? I might have more sympathy for this argument if the correct <unique null treatment> were non-default, but it is not. You'd have had to go out of your way to make the index incompatible. That in turn suggests that there's a mistake somewhere, so having the system automatically fix it for you might just be masking something that would be better dealt with manually. regards, tom lane
В списке pgsql-bugs по дате отправления: