On Mon, Sep 9, 2019 at 5:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org> writes:
> > On 2019-Sep-02, Tom Lane wrote:
> >> The right answer IMO is basically for the brinGetStats call to go
> >> away from brincostestimate and instead happen during plancat.c's
> >> building of the IndexOptInfo. In the case of a hypothetical index,
> >> it'd fall to the get_relation_info_hook to fill in suitable fake
> >> data.
>
> > So I'm not clear on what the suggested strategy is, here. Do we want
> > that design change to occur in the bugfix that would be backpatched, or
> > do we want the backbranches to use the patch as posted and then we apply
> > the above design on master only?
>
> The API change I'm proposing is surely not back-patchable.
>
> Whether we should bother back-patching a less capable stopgap fix
> is unclear to me. Yeah, it's a bug that an index adviser can't
> try a hypothetical BRIN index; but given that nobody noticed till
> now, it doesn't seem like there's much field demand for it.
> And I'm not sure that extension authors would want to deal with
> testing minor-release versions to see if the fix is in, so
> even if there were a back-patch, it might go unused.
FWIW I maintain such an extension and testing for minor release
version is definitely not a problem.