Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable
Date
Msg-id YWZViGJFJkrgBKwk@paquier.xyz
Whole thread Raw
In response to Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Wed, Oct 13, 2021 at 12:06:32AM +0000, Bossart, Nathan wrote:
> At first glance, it looks like ALTER INDEX .. ALTER COLUMN ... SET
> uses the wrong validation function.  I've attached a patch where I've
> attempted to fix that and added some tests.

The gap is larger than than, because ALTER INDEX .. ALTER COLUMN
.. SET is supported by the parser but we don't document it.  The only
thing we document now is SET STATISTICS that applies to a column
*number*.

Anyway, specifying a column name for an ALTER INDEX is not right, no?
Just take for example the case of an expression which has a hardcoded
column name in pg_attribute.  So these are not specific to indexes,
which is why we apply column numbers for the statistics case.  I think
that we'd better just reject those cases until there is a proper
design done here.  As far as I can see, I guess that we should do
things  similarly to what we do for SET STATISTICS with column
numbers when it comes to indexes.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [BUG] Unexpected action when publishing partition tables
Next
From: Michael Paquier
Date:
Subject: Re: Bug in DefineRange() with multiranges