Re: Define jsonpath functions as stable

On Mon, Jul 29, 2019 at 5:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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