On Mon, Jul 29, 2019 at 5:36 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > However, we've spotted some deviations between standard and our > > implementation. > > * like_regex predicate uses our regular expression engine, which > > deviates from standard. > > * We always do numeric computations using numeric datatype. Even if > > user explicitly calls .double() method. Probably, our current > > implementation still fits standard. But in future we may like to use > > floating point computation in some cases for performance optimization. > > ... > > Therefore, I'm going to mark jsonb_path_*() functions stable, not > > immutable. > > I dunno, I think you are applying a far more rigorous definition of > "immutable" than we ever have in the past. The possibility that we > might change the implementation in the future should not be enough > to disqualify a function from being immutable --- if that were the > criterion, nothing more complex than int4pl could be immutable. > > Wouldn't it be better that, in the hypothetical major version where > we change the implementation, we tell users that they must reindex > any affected indexes? > > As a comparison point, we allow people to build indexes on tsvector > results, which are *easy* to change just by adjusting configuration > files. The fact that this might force the need for reindexing hasn't > made it unworkable.
Thank you for the explanation. Given that there is no need to mark existing json_path_*() functions as stable. We can just advise users to rebuild their indexes if we have incompatible changes. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
