Re: ALTER TABLE ... SET STORAGE does not propagate to indexes
От | Peter Eisentraut |
---|---|
Тема | Re: ALTER TABLE ... SET STORAGE does not propagate to indexes |
Дата | |
Msg-id | 4e53fcdd-c427-6d3b-e871-9b7af0c36b70@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ... SET STORAGE does not propagate to indexes (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: ALTER TABLE ... SET STORAGE does not propagate to indexes
|
Список | pgsql-hackers |
On 2020-03-30 18:17, Alvaro Herrera wrote: > On 2020-Feb-25, Peter Eisentraut wrote: >> An alternative would be that we make this situation fully supported. Then >> we'd probably need at least ALTER INDEX ... ALTER COLUMN ... SET STORAGE, >> and some pg_dump support. > > I think this is a more promising direction. I have started implementing the ALTER INDEX command, which by itself isn't very hard, but it requires significant new infrastructure in pg_dump, and probably also a bit of work in psql, and that's all a bit too much right now. An alternative for the short term is the attached patch. It's the same as before, but I have hacked up the test_decoding test to achieve the effect of ALTER INDEX with direct catalog manipulation. This preserves the spirit of the test case, but allows us to fix everything else about this situation. One thing to remember is that the current situation is broken. While you can set index columns to have different storage than the corresponding table columns, pg_dump does not preserve that, because it dumps indexes after ALTER TABLE commands. So at the moment, having these two things different isn't really supported. The proposed patch just makes this behave consistently and allows adding an ALTER INDEX command later on if desired. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: