Re: point_ops for GiST

On Mon, Oct 12, 2015 at 12:47 PM, Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:

> > This was already fixed for GiST.
> > See following discussion
> >
> http://www.postgresql.org/message-id/CAPpHfdvGticGniaj88VCHzHboXJobUhjLm6c09q_Op_u9EoBFg@mail.gmail.com
> > and commit
> >
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3c29b196b0ce46662cb9bb7a1f91079fbacbcabb
> > "Consistent" method of GiST influences only search and can't lead to
> corrupt
> > indexes. However, "same" method can lead to corrupt indexes.
> > However, this is not the reason to not backpatch the changes and preserve
> > buggy behaviour; this is the reason to recommend reindexing to users.
> And it
> > was already backpatched.
>
> Fixing it on the opclass is not an option for BRIN. We designed BRIN
> opclasses extensible using extra SQL level support functions and
> operators. It is possible to support point datatype using box vs
> point operators. Doing so would lead to wrong results, because point
> operators use FP macros, but box_contain_pt() doesn't.
>

You still can workaround this problem in opclass. For instance, you can
assign different strategy number for this case. And call another support
function instead of overlap operator in brin_inclusion_consistent. For
sure, this would be a kluge.

> GiST opclass could be more clean and extensible, if we wouldn't have
> those macros.
>

In my opinion it would be cool remove FP macros. I see absolutely no sense
in them. But since it break compatibility it would be quite hard though.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company