Re: Rethinking opclass member checks and dependency strength

Darafei Komяpa Praliaskouski <me@komzpa.net>

From: Darafei "Komяpa" Praliaskouski <me@komzpa.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-08-09T14:19:35Z
Lists: 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.

Commits

  1. Invent "amadjustmembers" AM method for validating opclass members.

  2. Allow on-the-fly capture of DDL event details