Re: tsearch in core patch - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: tsearch in core patch
Date
Msg-id 1182455682.6146.4.camel@hannu-laptop
Whole thread Raw
In response to tsearch in core patch  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: tsearch in core patch
Re: tsearch in core patch
List pgsql-hackers
Ühel kenal päeval, N, 2007-06-21 kell 21:44, kirjutas Teodor Sigaev:
> http://www.sigaev.ru/misc/tsearch_core-0.52.gz
> 
> Plan was:
> 
> 1) rename FULLTEXT to TEXT SEARCH in SQL command
> done
> 
> 2) rework Snowball stemmer's as Tom suggested
> done
> 
> 3) ALTER FULLTEXT CONFIGURATION cfgname ADD/ALTER/DROP MAPPING
> done

Why not rename ALTER FULLTEXT CONFIGURATION --> ALTER TEXT SEARCH
CONFIGURATION here too ?

> 4) remove support of default configuration per scheme. Default configuration
>     will be only one per locale.
> done
> 
> 5) single encoded files. That will touch snowball, ispell, synonym, thesaurus
>     and simple dictionaries
> done
> 
> 6) use encoding names instead of locale's names in configuration
> Ugh. I missed that knowledge of encoding doesn't allow to determine exact 
> language

most languages can be written using UNICODE charset and UTF-8 encoding,
so neither charset not encoding can be used to determine language.

>  --- how do many languages use ISO8859-1 locale?. 

ISO8859-1 is encoding, not locale.

> So, it's not done. Tom 
> pointed that locale's name isn't portable, but there isn't a lot of names of the 
> same locale (ru_RU.UTF-8, ru_RU.UTF8 for example). So it's possible to use array 
> of locales instead of one name.
> 
> I didn't see comments about security hole pointed by Tom, so I repeat:
> 
> About security holes in PARSER/DICTIONARY. I see following ways to resolve it now:
> 1) Allow to superuser only to do CREATE/ALTER/DROP PARSER/DICTIONARY
>     Disadvantage: hosting users will not be able to change dictionaries
> 2) Remove CREATE/ALTER/DROP PARSER, split pg_ts_dict to pg_ts_dict_template
>     and pg_ts_dict and accordingly change CREATE/ALTER/DROP DICTIONARY
>     Disadvantage: parser and dictionary's template will not dump/restore,
>                   it should be restored manually (just a INSERT into
>                   pg_ts_parser/pg_ts_dict_template)
> 3) Similar to previous point, but:
>     * CREATE/ALTER/DROP PARSER - super-user only
>     * CREATE/ALTER/DROP DICTIONARY TEMPLATE - super-user only
>     * CREATE/ALTER/DROP DICTIONARY - allowed to non-superuser
>     Disadvantage: new command CREATE/ALTER/DROP DICTIONARY TEMPLATE
> Which way do we choose? or I miss some variant?
> 
> I would like to go by 3) way... Comments?
> 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: What does Page Layout version mean? (Was: Re: Reducing NUMERIC size for 8.3)
Next
From: Tom Lane
Date:
Subject: Re: tsearch in core patch