After looking at this more closely, I wonder if this is really doing
what we want. For BRIN and GiST, you can only pass an index to the
brin_page_items and gist_page_items functions respectively, and that
only as to let the function know what relation the page comes from. The
actual read from the index comes from get_raw_page().
So in the regression database, I created
create index on regress_constr_partitioned using brin (a);
and then tried this
select * from brin_page_items(get_raw_page('regress_constr_partitioned_a_idx1',
1), 'regress_constr_partition1_a_idx'::regclass);
this gives me the following existing error:
ERROR: cannot get raw page from relation "regress_constr_partitioned_a_idx1"
DETALLE: This operation is not supported for partitioned indexes.
but if I instead do it the other way around,
select * from brin_page_items(get_raw_page('regress_constr_partition1_a_idx',
1), 'regress_constr_partitioned_a_idx1'::regclass);
the error is now
ERROR: "regress_constr_partitioned_a_idx1" is not a BRIN index
I wonder ... shouldn't these reports be more similar? Or, there's also
the alternative view that we don't _need_ to throw an error here. If I
remove the new check, I get this
select * from brin_page_items(get_raw_page('regress_constr_partition1_a_idx',
2), 'regress_constr_partitioned_a_idx1'::regclass);
itemoffset │ blknum │ attnum │ allnulls │ hasnulls │ placeholder │ empty │
value
────────────┼────────┼────────┼──────────┼──────────┼─────────────┼───────┼───────
1 │ 0 │ 1 │ t │ f │ f │ t │
(1 fila)
which seems ... perfectly okay? I mean, why are you worried about this?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Computing is too important to be left to men." (Karen Spärck Jones)
