Re: default_text_search_config and expression indexes

Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> However, the big problem is that the expressions used in expression
>>> indexes should not change their output based on the value of a GUC
>>> variable (because it would corrupt the index), but in the case above,
>>> default_text_search_config controls what configuration is used, and
>>> hence the output of to_tsvector is changed if default_text_search_config
>>> changes.
>> It wuoldn't actually *corrupt* the index, right? You could end up with
>> wrong results, which might be regarded as corruption in one way, but as
>> long as you change the value back the index still works, no?
> 
> Right, it would _temporarily_ corrupt it.  ;-)
> 
>>> We have a few possible options:
>>>
>>>     1) Document the problem and do nothing else.
>>>     2) Make default_text_search_config a postgresql.conf-only
>>>        setting, thereby making it impossible to change by non-super
>>>        users, or make it a super-user-only setting.
>>>     3) Remove default_text_search_config and require the
>>>        configuration to be specified in each function call.
>>>
>>> If we remove default_text_search_config, it would also make ::tsvector
>>> casting useless as well.
>> I think 3 is a really bad solution.
>>
>> 2 is a half-bad solution. Do we have a way to say that it can be set at
>> database-level for example, but not at user session? Making it
>> superuser-only to change it but not postgresql.conf-only could accomplish
>> that, along with warnings in the docs for the super user about the effects
>> on current indexes by changing it.
> 
> OK, here is what I am thinking.  If we make default_text_search_config
> super-user-only, then the user can't do SET (using "zero_damaged_pages"
> as a superuser-only example):
> 
>     test=> set zero_damaged_pages = on;
>     ERROR:  permission denied to set parameter "zero_damaged_pages"
>     
>     test=> alter user guest set zero_damaged_pages = on;
>     ERROR:  permission denied to set parameter "zero_damaged_pages"
> 
> but the super-user can set it in postgresql.conf, or:
> 
>     test=# alter user guest set zero_damaged_pages = on;
>     ALTER ROLE
> 
> or
> 
>     test=# alter database vendor3 set zero_damaged_pages = on;
>     ALTER ROLE
> 
> meaning while it will be super-user-only, the administrator can set the
> default for specific databases and users.  Is that the best approach?

That's exactly the one I was trying to suggest. And then with clear
warnings in the docs around the place that if you set it to different
values accessing the same index (for different users, for example) weird
things may happen.

But I see the ALTER DATABASE a fairly common scenario (I know I would
use it), and from what I can tell thereis no risk at all with that.

//Magnus