Re: Define jsonpath functions as stable - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Define jsonpath functions as stable
Date
Msg-id CAPpHfduWhRbN-DTguMXfn4xCSe_tg3zwN=aWy=wk3PNUB+g0-Q@mail.gmail.com
Whole thread Raw
In response to Re: Define jsonpath functions as stable  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 29, 2019 at 5:36 PM Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Sehrope Sarkuni
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Joe Conway
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)