On 2021-Mar-22, Tomas Vondra wrote: > I don't know what's the right fix, but it seems like this patch has > nothing to do with it. If we want to move the opclasses into an > extension, we can comment out that one (cidr/inet) case for now.
I don't know what would be a good reason to define the opclasses in separate contrib extensions. I think it's going to be a nuisance to users, so unless there is some strong argument for it, I'd suggest not to do it. I found it being discussed here: https://www.postgresql.org/message-id/CA%2BTgmoajaQKBUx%3DvaTUFo6z80dsRzBw__Nu41Q4t06baZep3Ug%40mail.gmail.com but there weren't any strong arguments put forward. It seems a good experiment to have done it, though, since we now know that there is a limitation in the existing SQL interface. Maybe the fix to that problem is to add a new clause to CREATE/ALTER OPERATOR CLASS to let you define what goes into opckeytype. However I don't think it's this patch's responsibility to fix that problem. -- Álvaro Herrera Valdivia, Chile "Hay que recordar que la existencia en el cosmos, y particularmente la elaboración de civilizaciones dentro de él no son, por desgracia, nada idílicas" (Ijon Tichy)
