MIME-Version: 1.0
References: <5fd19680-c0db-e9ea-eae6-971a369b4233@enterprisedb.com>
In-Reply-To: <5fd19680-c0db-e9ea-eae6-971a369b4233@enterprisedb.com>
Reply-To: emre@hasegeli.com
From: Emre Hasegeli <emre@hasegeli.com>
Date: Thu, 14 Dec 2023 12:35:17 +0100
Message-ID: <CAE2gYzw=g5Cfyuo_jkhMey8jDFTxDyV3CNRp6eS8EHXYBajQLA@mail.gmail.com>
Subject: Re: btree_gist into core?
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAE2gYzw%3Dg5Cfyuo_jkhMey8jDFTxDyV3CNRp6eS8EHXYBajQLA%40mail.gmail.com>
Precedence: bulk

> Thoughts?

I think it'd be really nice to do this without btree_gist.

I imagine something like this:

CREATE INDEX ON tbl USING gist (
    range_col,
    int_col USING btree
)

I think this would make the index access methods interface more
useful.  Index access method developers wouldn't need to provide
operator classes for all data types.  We could extend ACCESS METHOD
definition to allow this:

CREATE ACCESS METHOD my_hash_index
    TYPE INDEX
    IMPLEMENTS hash
    HANDLER my_hash_index_handler

I realise this is a difficult project.