Re: Add IS_INDEX macro to brin and gist index

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Japin Li <japinli(at)hotmail(dot)com>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add IS_INDEX macro to brin and gist index
Date: 2026-01-14 15:40:16
Message-ID: 202601141537.xogppfpwrpyh@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Jan-14, Japin Li wrote:

> -#define IS_INDEX(r) ((r)->rd_rel->relkind == RELKIND_INDEX)
> -#define IS_BTREE(r) ((r)->rd_rel->relam == BTREE_AM_OID)
> +#define IS_BTREE(r) (IS_INDEX(r) && (r)->rd_rel->relam == BTREE_AM_OID)

I find this coding rather pointless. You can more easily do something
like

#define IS_BTREE(r) ((r)->rd_rel->relkind == RELKIND_INDEX && (r)->rd_rel->relam == BTREE_AM_OID)

and get rid of the IS_INDEX macro completely, if it's not used anywhere
else. Same for all the other index AMs.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuya Kawata 2026-01-14 15:43:32 Re: [PATCH] Add sampling statistics to autoanalyze log output
Previous Message Robert Haas 2026-01-14 15:38:12 Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables