On Sat, Oct 3, 2020 at 4:01 PM Tomas Vondra <tomas.von...@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
