Re: ALTER TABLE ... SET STORAGE does not propagate to indexes

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-04-09T13:07:40Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Propagate ALTER TABLE ... SET STORAGE to indexes

Attachments

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