On Mon, Sep 9, 2019 at 5:03 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera from 2ndQuadrant <alvhe...@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.
