Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> During my work on bringing jsonpath patchset to commit, I was always
> keeping in mind that we need to make jsonb_path_*() functions
> immutable. Having these functions immutable, users can build
> expression indexes over them.
Right.
> 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.
regards, tom lane
