Andreas Karlsson <andreas@proxel.se> writes:
> This has been broken for as long as we have had btree_gist indexes over
> inet. And personally I am not a fan of PostgreSQL shipping with known
> broken features. But it is also not obvious to me what the best way to
> fix it is.
Yeah, this has been lingering unfixed precisely for lack of a clearly-
good fix.
> Is it even worth fixing btree_gist for inet when we already have
> inet_ops which can do more things and is not broken. We could just
> deprecate and then rip out gist_inet_ops?
That might be the thing to do; it doesn't seem very nice to carry
essentially duplicate functionality. However
(1) is performance as good?
(2) gist inet_ops is not marked default, so we'd have to change that.
I don't recall what happens if there are two default opclasses
for the same AM and input type, but it's likely not great.
> If we are going to fix it I cannot see any reasonably sized fix which
> does not also corrupt all existing indexes on inet, even those which do
> not contain any net masks (those which contain netmasks are already
> broken anyway). Do we have some way to handle this kind of breakage nicely?
Not really. If the fix involves changing the declared storage type for
an inet column, we might be able to have the support routines check that,
and either error out or continue to do what they used to. But I'm not
sure whether that info is available to all the support routines.
pg_upgrade scenarios might be messy, too.
regards, tom lane
