At Tue, 27 Nov 2018 06:33:42 +0100, Laurenz Albe <laurenz.albe@cybertec.at> wrote in
<8dcb0bb248e9aaef0f1ef0faa27ab583bfa5bb84.camel@cybertec.at>
> On Mon, 2018-11-26 at 19:51 -0500, Stephen Frost wrote:
> > If a function's results can change across minor or major versions, we
> > shouldn't be marking it as immutable because, by definition, it's not
> > immutable.
> >
> > We, today, have a baked in assumption that any function marked as
> > immutable will remain immutable across all major versions that we allow
> > indexes to be retained through, which is all of them since about 8.3 at
> > this point.
> >
> > We absolutely need a policy that if you decide to change the results of
> > some immutable function across a major version change, you need to
> > consider the results on indexes and possibly write into pg_upgrade
> > checks to try and detect any usage of that immutable function. I hope
> > we're in agreement there.
>
> It's hard to make a guarantee that a function will never change in the
> future. What if we fix some rounding or overflow problem in a floating
> point function?
+1.
Actually, some geometric comparisons are performed counting
tolerance margin, the validity of which is in doubt. Their
behavior has been changed in recent major version and still has a
room for improvement, and the functions are parallel-safe and
immutable. Immutablity is mentiond mainly in the light of
optimization in the documentation.
https://www.postgresql.org/docs/current/xfunc-volatility.html
> If we went that far, hardly any function could be IMMUTABLE.
>
> I think it is best to use IMMUTABLE whenever we don't expect it to
> change and it is a function useful for indexes, and if it happens to
> change nonetheless, write into the release notes that certain indexes
> have to be rebuilt after upgrade.
> Of course, there is no problem to mark pg_config as stable, because
> there is little chance it will be used in an index anyway.
Agreed. We have the following description in the documentation.
| A common error is to label a function IMMUTABLE when its results
| depend on a configuration parameter. For example, a function that
| manipulates timestamps might well have results that depend on the
| TimeZone setting. For safety, such functions should be labeled
| STABLE instead.
Still this isn't mentioning upgrades. We could add to this that
something like that immutablity is not guaranteed beyond
PostgreSQL versions, the results of immutable functions might
change for certain reasons including bug fixes, blah, blah..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center