Re: Allowing extensions to supply operator-/function-specific info

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 29 Jan 2019 at 09:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I have no particular
>> interest in working on that right now, because it doesn't respond to
>> what I understand PostGIS' need to be, and there are only so many
>> hours in the day. But maybe it could be made workable in the future.

> I thought the whole exercise was about adding generic tools for everybody
> to use.

Well, I'm building infrastructure plus a small subset of what might
someday sit atop that infrastructure. I'm not prepared to commit
right now to building stuff I can't finish for v12.

> You said PostGIS was looking to
> "automatically convert WHERE clauses into lossy index quals." which sounds
> very similar to what I outlined.

As I understand it, what they have is complex WHERE clauses from which
they want to extract clauses usable with simple (non-expression) indexes.
The case you seem to be worried about is the reverse: complicated index
definition and simple WHERE clause. I think we're agreed that these two
cases can't be solved with the very same facility. The support-function
mechanism probably can be used to provide extensibility for logic that
tries to attack the complicated-index case, but its mere existence won't
cause that logic to spring into being.

regards, tom lane