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[, ...];
 REPLACE olddictname TO newdictname;
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: [EMAIL PROTECTED]
                                                   WWW: http://www.sigaev.ru/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to