On Sat, Oct 3, 2020 at 4:01 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On Sat, Oct 03, 2020 at 02:13:01PM +0200, Petru Ghita wrote:
> >As instructed by Alexander Korotkov, I'm linking the patch:
> >
> >https://github.com/petru-ghita/postgres/commit/d6d1f340cd34db8176744ede7f0fe588d870a33f
> >
>
> Please submit an actual patch, not just a link to github commit. That
> may disappear in the future, and we want an actual copy here in the
> archives. Also, we have a bot that tests patches sent as attachments,
> and the github commit can't benefit from that either.
+1
> Also, add the patch to the next commitfest (i.e. 2020-11) here:
>
> https://commitfest.postgresql.org/
+1
> As for the patch, I wonder if we want to make this change. I'm not very
> familiar with how unaccent works, but if changes to unicode rules would
> really silently break indexes, it's kinda similar to the collation
> issues caused by glibc updates. And we've generally considered that a
> case of data corruption, I think, so it'd be strange to allow that here.
>
> If a user really wants to allow this, it's possible to create a stable
> wrapper function - the difference is that if it breaks, it's the user's
> responsibility to deal with that.
I personally don't have an exact understanding of how strict we are
about marking functions immutable. For example,
to_tsvector(regconfig, text) is immutable. However, underlying
dictionaries in fulltext search configuration may change behavior in
major releases. Even unaccent defines a dictionary. So, it might be
used inside an immutable function in a "legal way" without explicitly
placing responsibility for that to the user. I've raised a similar
question about jsonpath[1], because it's immutable functions are going
to change their behavior in future. An answer by Tom Lane [2], shows
that it's not completely unacceptable to sometimes change behavior of
immutable function in a major release.
As I get currently there is no rule "function behavior might be
changed in major release" => "function can't be marked as immutable".
So, we've to consider risks in each case individually.
Links
1. https://www.postgresql.org/message-id/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg%40mail.gmail.com
2. https://www.postgresql.org/message-id/9219.1564410991%40sss.pgh.pa.us
------
Regards,
Alexander Korotkov