Re: WIP: BRIN multi-range indexes

On Wed, Mar 13, 2019 at 12:52 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> On 3/13/19 9:15 AM, Alexander Korotkov wrote:
> > On Tue, Mar 12, 2019 at 8:15 PM Tomas Vondra
> > <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> >>> 0001. Pass all keys to BRIN consistent function at once.
> >>>
> >>> I think that changing the signature of consistent function is bad, because then
> >>> the authors of existing BRIN opclasses will need to maintain two variants of
> >>> the function for different version of PosgreSQL. Moreover, we can easily
> >>> distinguish two variants by the number of parameters. So I returned back a
> >>> call to old 3-argument variant of consistent() in bringetbitmap(). Also I
> >>> fixed brinvalidate() adding support for new 4-argument variant, and fixed
> >>> catalog entries for brin_minmax_consistent() and brin_inclusion_consistent()
> >>> which remained 3-argument. And also I removed unneeded indentation shift in
> >>> these two functions, which makes it difficult to compare changes, by extracting
> >>> subroutines minmax_consistent_key() and inclusion_consistent_key().
> >>>
> >>
> >> Hmmm. I admit I rather dislike functions that change the signature based
> >> on the number of arguments, for some reason. But maybe it's better than
> >> changing the consistent function. Not sure.
> >
> > I also kind of dislike signature change based on the number of
> > arguments. But it's still good to let extensions use old interface if
> > needed. What do you think about invention new consistent method, so
> > that extension can implement one of them? We did similar thing for
> > GIN (bistate consistent vs tristate consistent).
> >
>
> Possibly. The other annoyance of course is that to support the current
> consistent method we'll have to keep all the code I guess :-(

Yes, because incompatible change of opclass support function signature
is the thing we never did before. We have to add new optional
arguments to GiST functions, but that was compatible change.

If we do incompatible change of opclass interface, it becomes unclear
to do pg_upgrade with extension installed. Imagine, if we don't
require function signature to match, we could easily get segfault
because of extension incompatibility. If we do require function
signature to match, extension upgrade would become complex. It would
be required to not only adjust C-code, but also write some custom
script, which changes opclass (and users would have to run this script
manually?).

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