Re: WIP: BRIN multi-range indexes - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: WIP: BRIN multi-range indexes
Date
Msg-id CAPpHfdsC8Y8+2ZvDM6m_7E6ZN7b0ev4Z2LvHd6tJCCsTsnGVrg@mail.gmail.com
Whole thread Raw
In response to Re: WIP: BRIN multi-range indexes  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: WIP: BRIN multi-range indexes
List pgsql-hackers
On Tue, Mar 12, 2019 at 8:15 PM Tomas Vondra
<tomas.vondra@2ndquadrant.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).

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


pgsql-hackers by date:

Previous
From: "Nagaura, Ryohei"
Date:
Subject: RE: Timeout parameters
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Introduce timeout capability for ConditionVariableSleep