Re: tsearch_core patch: permissions and security issues - Mailing list pgsql-hackers

>> Well assuming we have any SQL-level support at all I think we should
>> strive to avoid these functions taking INTERNAL arguments.
> That gets us down to just needing to worry about whether we like the
> SQL representation of configurations.  Which is still a nontrivial
> issue, but at least it seems manageable on a timescale that's
> reasonable for 8.3.

Possible solution is to split pg_ts_dict (I'll talk about dictionaries, but the 
same way is possible to parsers, but now it's looked as overdesign) to two table 
like pg_am and pg_opclass.
First table, pg_ts_dict_template (I don't know the exact name yet) which 
contains columns: oid, template_name, dict_init, dict_lexize and second:
pg_ts_dict with colimns: oid, template_oid, owner, schema, dict_initoption.

CREATE/ALTER/DROP DICTIONARY affects only second table and access to first one 
is only select/update/insert/delete similar to pg_am.

IMHO, this interface solves problems with security and dumping.

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.

Next, INTERNAL arguments parser's and dictionary's APIs are used because if 
performance reason. During creation of tsvector from text, there are a lot of 
calls of parsers and dictionaries. And internal structures of they states may be 
rather complex and cannot be matched in any pgsql's type, even in flat memory 
structure.

> 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?
> TSConfiguration objects are a different story, since they have only> type-safe dependencies on parsers, locales, and
dictionaries. But they> still need some more thought about permissions, because AFAICS mucking> with a configuration
caninvalidate some other user's data.Do we want> to allow runtime changes in a configuration that existing tsvector>
columnsalready depend on?  How can we even recognize whether there is> stored data that will be affected by a
configurationchange?  (AFAICS
 

Very complex task: experienced users could use several configuration 
simultaneously. For example: indexing use configuration which doesn't reject 
stop-words, but for default searching use configuration which rejects 
stop-words. BTW, the same effects may be produced by dictionary's change.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/