Re: Remove IndexInfo.ii_OpclassOptions field - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Remove IndexInfo.ii_OpclassOptions field
Date
Msg-id 38128793-278d-7cb2-5bcf-8a7849e23e98@eisentraut.org
Whole thread Raw
In response to Re: Remove IndexInfo.ii_OpclassOptions field  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove IndexInfo.ii_OpclassOptions field
List pgsql-hackers
On 25.08.23 03:31, Michael Paquier wrote:
> On Thu, Aug 24, 2023 at 08:57:58AM +0200, Peter Eisentraut wrote:
>> During some refactoring I noticed that the field IndexInfo.ii_OpclassOptions
>> is kind of useless.  The IndexInfo struct is notionally an executor support
>> node, but this field is not used in the executor or by the index AM code.
>> It is really just used in DDL code in index.c and indexcmds.c to pass
>> information around locally.  For that, it would be clearer to just use local
>> variables, like for other similar cases.  With that change, we can also
>> remove RelationGetIndexRawAttOptions(), which only had one caller left, for
>> which it was overkill.
> 
> I am not so sure.  There is a very recent thread where it has been
> pointed out that we have zero support for relcache invalidation with
> index options, causing various problems:
> https://www.postgresql.org/message-id/CAGem3qAM7M7B3DdccpgepRxuoKPd2Y74qJ5NSNRjLiN21dPhgg%40mail.gmail.com
> 
> Perhaps we'd better settle on the other one before deciding if the
> change you are proposing here is adapted or not.

Ok, I'll wait for the resolution of that.

At a glance, however, I think my patch is (a) not related, and (b) if it 
were, it would probably *help*, because the change is to not allocate 
any long-lived structures that no one needs and that might get out of date.




pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw: wrong results with self join + enable_nestloop off
Next
From: Amit Kapila
Date:
Subject: Re: persist logical slots to disk during shutdown checkpoint