From: | Laurence Parry <greenreaper(at)hotmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Naming of network_ops vs. inet_ops for SP-GIST |
Date: | 2023-01-24 21:34:32 |
Message-ID: | PA4PR07MB891006E0DA3E4ADB972E48F4A5C99@PA4PR07MB8910.eurprd07.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
> This naming was evidently chosen to match btree,
> which has both inet_ops and cidr_ops opclasses
> within its network_ops family.
> spgist only supports inet_ops
FWIW, the documentation for GIST has inet_ops in the equivalent table, so it was extra-confusing because I thought SP-GIST's inconsistency must have a reason - though I see now using '\dAf gist' suggests it's similar.
https://www.postgresql.org/docs/14/gist-builtin-opclasses.html
The index in question was replacing a default btree - we'd started using the table to block by range; when reviewing indexes, I found it wasn't used anymore. (I didn't know btree *had* cidr_ops, but that may be for the best, as it didn't help with 'CIDR contains IP'.)
Best regards,
--
Laurence 'GreenReaper' Parry
greenreaper.co.uk - Inkbunny.net
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-01-25 02:45:22 | Re: Naming of network_ops vs. inet_ops for SP-GIST |
Previous Message | Tom Lane | 2023-01-24 20:22:44 | Re: Naming of network_ops vs. inet_ops for SP-GIST |