Re: tsearch_core patch: permissions and security issues
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Teodor Sigaev <teodor@sigaev.ru>
Cc: Gregory Stark <stark@enterprisedb.com>, Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgresql.org
Date: 2007-06-14T18:54:07Z
Lists: pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes: > The reason to save SQLish interface to dictionaries is a simplicity of > configuration. Snowball's stemmers are useful as is, but ispell dictionary > requires some configuration action before using. Yeah. I had been wondering about moving the dict_initoption over to the configuration entry --- is that sane at all? It would mean that dict_init functions would have to guard themselves against invalid options, but they probably ought to do that anyway. If we did that, I think we could have a fixed set of dictionaries without too much problem, and focus on just configurations as being user-alterable. >>> Next, it took me a while to understand how Mapping objects fit into >>> the scheme at all, and now that (I think) I understand, I'm wondering >>> why treat them as an independent concept. > ALTER FULLTEXT CONFIGURATION cfgname ADD MAPPING FOR tokentypename[, ...] WITH > dictname1[, ...]; > ALTER FULLTEXT CONFIGURATION cfgname ALTER MAPPING FOR tokentypename[, ...] WITH > dictname1[, ...]; > ALTER FULLTEXT CONFIGURATION cfgname ALTER MAPPING [FOR tokentypename[, ...]] > REPLACE olddictname TO newdictname; > ALTER FULLTEXT CONFIGURATION cfgname DROP MAPPING [IF EXISTS] FOR tokentypename; > Is it looking reasonable? Er ... what's the difference between the second and third forms? regards, tom lane