coupling of index and table access methods
Hi hackers,
My extension introduces a new table access method together with an
index access method. Specifically, these AMs work with in-memory data.
I would like to make a CREATE TABLE request with PRIMARY KEY, UNIQUE
constraints etc, to pick my in-memory index AM over default btree when
the table is created using my in-memory table AM. Also it might make
sense to forbid using other index AM for CREATE INDEX requests against
an in-memory table.
It seems that this is not possible now without modifying the psql
core. What might be the best way to accomplish this?
Also if I implement such a thing would anybody else be interested in
it? Is there any sense to publish it?
Regards,
Aleksey
As far as I see a possible way to do this is to add two optional
functions to table AM interface:
char * (*default_index_am)(void) ;
bool (*validate_index_am)(char *);
If the first one is not provided then DEFAULT_INDEX_TYPE, that is
"btree", has to be used instead. If the second one is not provided
then this as if it always returned true.
But in other places DEFAULT_INDEX_TYPE should be replaced with
invocation of (table_am->default_index_am)(). This is not always
possible directly, e.g. we don't yet have the table_am here:
access_method_clause:
USING name { $$ = $2; }
| /*EMPTY*/ { $$ =
DEFAULT_INDEX_TYPE; }
;
So in places like this some placeholder has to be used instead which
would be replaced with a real thing at some later point.
Regards,
Aleksey
Show quoted text
On Tue, Oct 1, 2024 at 4:51 PM Aleksey Demakov <ademakov@gmail.com> wrote:
Hi hackers,
My extension introduces a new table access method together with an
index access method. Specifically, these AMs work with in-memory data.I would like to make a CREATE TABLE request with PRIMARY KEY, UNIQUE
constraints etc, to pick my in-memory index AM over default btree when
the table is created using my in-memory table AM. Also it might make
sense to forbid using other index AM for CREATE INDEX requests against
an in-memory table.It seems that this is not possible now without modifying the psql
core. What might be the best way to accomplish this?Also if I implement such a thing would anybody else be interested in
it? Is there any sense to publish it?Regards,
Aleksey