Re: tsearch_core patch: permissions and security issues

>> 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 can invalidate some other user's data.Do we want
> to allow runtime changes in a configuration that existing tsvector
> columns already depend on? How can we even recognize whether there is
> stored data that will be affected by a configuration change? (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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/