| From: | Japin Li <japinli(at)hotmail(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| 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-20 09:02:19 |
| Message-ID: | MEAPR01MB303101194936F6A1C7A203BEB689A@MEAPR01MB3031.ausprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 16 Jan 2026 at 09:55, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> On 2026-Jan-16, Japin Li wrote:
>
>> Thanks for the test. After rethinking, I agree — that BRIN/GIST index-type
>> check is useless.
>>
>> OTOH, why don't we just do it the same way as the btree index functions?
>>
>> brin_page_items(relname text, blkno bigint);
>
> Operational usefulness. If you have a corrupt page in a production, you
> can extract it from there with get_raw_page() and move it to another
> system to do low-level investigation. If you only have the interface
> you suggest, you force the researcher to access the production system
> (and run potentially dangerous tools), which may be best avoided.
>
Sorry, I didn't get your mind. We can still use get_raw_page().
> --
> Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jakub Wartak | 2026-01-20 09:19:48 | Re: pg_plan_advice |
| Previous Message | vignesh C | 2026-01-20 08:54:01 | Re: Logical Replication of sequences |