Re: allowing extensions to control planner behavior - Mailing list pgsql-hackers

From Robert Haas
Subject Re: allowing extensions to control planner behavior
Date
Msg-id CA+TgmoZV+O0DYj0h-_BG-S=3w-6CBoi5YzQ8YsUud1tREcXQaw@mail.gmail.com
Whole thread Raw
In response to Re: allowing extensions to control planner behavior  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Tue, Aug 27, 2024 at 11:57 AM Joe Conway <mail@joeconway.com> wrote:
> On the one hand, excluding indexes by initial vowels is definitely
> silly. On the other, I can see how it might be useful for an extension
> to exclude indexes based on a regex match of the index name or something
> similar, at least for testing.

Right. I deliberately picked a contrib module that implemented a silly
policy, because what I wanted to demonstrate with it is that this
little bit of infrastructure provides enough mechanism to implement
whatever policy you want. And I think it demonstrates it quite well,
because the whole contrib module to implement this has just 6 lines of
executable code. If you wanted a policy that would be more
realistically useful, you'd need more code, but only however much is
needed to implement your policy. All you need do is replace this
strchr call with something else:

                if (name != NULL && strchr("aeiouAEIOU", name[0]) != NULL)
                        index->disabled = true;

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
Next
From: Tom Lane
Date:
Subject: Re: allowing extensions to control planner behavior