Thread

1. Sharp edge when dropping columns

   Quentin de Metz <quentin@de.me.tz> — 2024-03-14T18:44:31Z

   [This is my first message on a PG mailing list, here's hoping I'm not breaching etiquette somehow]
   
   Bonjour,
   
   I'd like to report a sharp edge which caused downtime in my production application: dropping a column which is INCLUDEd in an index drops the index. 
   
   In the past, I have included a field in some of my indexes so that related queries can be performed as an index-only scan. This field was later deprecated. When the related column was ultimately dropped, the performance of the initial queries ground to a halt because the underlying index had been dropped.
   
   I found this behavior unexpected. I think preventing the index from being dropped in some circumstances would make this less surprising. The exact circumstances likely need to be hashed out if there is a consensus that this is a (minor) problem.
   
   Please find below a simple reproduction script:
   
   =# CREATE TABLE test (id bigint, label text);
   CREATE TABLE
   
   =# CREATE INDEX pkey_with_label ON test USING btree (id) INCLUDE (label);
   CREATE INDEX
   
   =# \d test
   Table "public.test"
   ┌────────┬────────┬───────────┬──────────┬─────────┐
   │ Column │ Type   │ Collation │ Nullable │ Default │
   ├────────┼────────┼───────────┼──────────┼─────────┤
   │ id     │ bigint │           │          │         │
   │ label  │ text   │           │          │         │
   └────────┴────────┴───────────┴──────────┴─────────┘
   Indexes:
   "pkey_with_label" btree (id) INCLUDE (label)
   
   =# ALTER TABLE test DROP COLUMN label;
   ALTER TABLE
   
   =# \d test
   Table "public.test"
   ┌────────┬────────┬───────────┬──────────┬─────────┐
   │ Column │ Type   │ Collation │ Nullable │ Default │
   ├────────┼────────┼───────────┼──────────┼─────────┤
   │ id     │ bigint │           │          │         │
   └────────┴────────┴───────────┴──────────┴─────────┘
   
   Thank you for reading,
   
   Quentin de Metz

2. Re: Sharp edge when dropping columns

   David G. Johnston <david.g.johnston@gmail.com> — 2024-03-14T19:01:30Z

   On Thu, Mar 14, 2024 at 11:45 AM Quentin de Metz <quentin@de.me.tz> wrote:
   
   >
   > I found this behavior unexpected.
   >
   
   In general it is advisable to rely on documented behaviors rather than
   expectations.
   
   https://www.postgresql.org/docs/current/sql-altertable.html
   
   This long-standing behavior seems unlikely to be changed.  Preventing the
   column from being dropped would in any case be the accepted outcome, not
   leaving an index behind that refers to a column that doesn't exist.
   
   David J.
   

3. Re: Sharp edge when dropping columns

   Tom Lane <tgl@sss.pgh.pa.us> — 2024-03-14T19:17:12Z

   "Quentin de Metz" <quentin@de.me.tz> writes:
   > I'd like to report a sharp edge which caused downtime in my production application: dropping a column which is INCLUDEd in an index drops the index. 
   
   This behavior is intentional, and we're not likely to change it.
   
   			regards, tom lane