From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Petru Ghita <petru(dot)ghita(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POC: contrib/unaccent as IMMUTABLE |
Date: | 2020-10-03 20:13:28 |
Message-ID: | CAPpHfdvgW+xLoX9nm5yys4nb_bk9CxB44_gXJg62epB7PLLh6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 3, 2020 at 6:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> > 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.
>
> Yeah. This is in fact wrong, because a TS configuration can *very*
> easily be changed by the user. We held our noses and did it anyway
> to allow tsvector results to be stored in indexes, figuring that
> (a) we'd put it on the user's head to reindex when necessary, and
> (b) in most situations, small changes in a TS configuration don't
> make an old tsvector index unusable --- at worst, some searches
> will fail that should have succeeded. (I'm not entirely sure that
> I believe (b), but that was the argument that was advanced.)
>
> I do not think we'd accept such a compromise if it were put forward
> today. The project's standards for such things have tightened over
> time, as evidenced by the work that's going towards collation
> change detection.
>
> It's also worth noting that the consequences of an out-of-date
> index for unaccent seem likely to be worse than they are for
> tsvectors. It's not hard to imagine somebody making a unique
> index on an unaccent result, and then setting themselves up for
> dump/reload failures by changing the unaccent rules. Nobody
> builds unique indexes on tsvectors.
Tom, thank you for the clarification. Now I get more understanding on
the project policy here. I agree that we shouldn't mark unaccent() as
immutable in the current infrastructure.
------
Regards,
Alexander Korotkov
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-10-03 20:57:03 | Re: Optimize memory allocation code |
Previous Message | Andres Freund | 2020-10-03 19:03:05 | Re: Incorrect assumption in heap_prepare_freeze_tuple |