Re: Rethinking opclass member checks and dependency strength - Mailing list pgsql-hackers

From Darafei "Komяpa" Praliaskouski
Subject Re: Rethinking opclass member checks and dependency strength
Date
Msg-id CAC8Q8tKYcE2JU6Whz2hqo1H9tY1zM26yf99RnDFgTGRiCNfskQ@mail.gmail.com
Whole thread Raw
In response to Rethinking opclass member checks and dependency strength  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
But none of our contrib modules do it like that, and I'd lay long odds against any third party code doing it either.

Thoughts? 
 

PostGIS has some rarely used box operations as part of GiST opclass, like "overabove". 

These are source of misunderstanding, as it hinges on the fact that non-square geometry will be coerced into a box on a call, which is not obvious when you call it on something like diagonal linestrings.
It may happen that we will decide to remove them. On such circumstances, I expect that ALTER OPERATOR CLASS DROP OPERATOR will work. 

Other thing that I would expect is that DROP FUNCTION ... CASCADE will remove the operator and unregister the operator from operator class without dropping operator class itself.

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Global temporary tables
Next
From: Alexander Korotkov
Date:
Subject: Re: SQL/JSON path: collation for comparisons, minor typos in docs