Re: Add IS_INDEX macro to brin and gist index - Mailing list pgsql-hackers

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)