Thread: Is ALTER TEXT SEARCH CONFIGURATION PARSER = new_parser really sane?
After starting to document this stuff I'm wondering whether it really
makes sense to change the parser associated with a tsearch
configuration. The problem is that the new parser might have an
unrelated set of token types, but we don't do anything about updating
the configuration's mappings.
Ensuring sane behavior here would take a whole lot of new code, and
I'm not sure that I see a use-case that justifies it. So I'm tempted to
take out that particular ALTER capability altogether. I note that the
corresponding feature of changing a dictionary's template on-the-fly
doesn't exist (though it'd actually be a lot easier to support).
Comments?
regards, tom lane
Tom Lane wrote: > After starting to document this stuff I'm wondering whether it really > makes sense to change the parser associated with a tsearch > configuration. The problem is that the new parser might have an > unrelated set of token types, but we don't do anything about updating > the configuration's mappings. > > Ensuring sane behavior here would take a whole lot of new code, and > I'm not sure that I see a use-case that justifies it. So I'm tempted to > take out that particular ALTER capability altogether. I note that the > corresponding feature of changing a dictionary's template on-the-fly > doesn't exist (though it'd actually be a lot easier to support). > > Comments? Agreed, the parser should be a central part of the configuration and changing it seems odd. If someone really wanted to change it they can create a new configuration with a new parser, then rename the new one into place. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, 21 Aug 2007, Tom Lane wrote:
> After starting to document this stuff I'm wondering whether it really
> makes sense to change the parser associated with a tsearch
> configuration. The problem is that the new parser might have an
> unrelated set of token types, but we don't do anything about updating
> the configuration's mappings.
looks reasonable, we could always create new parser.
>
> Ensuring sane behavior here would take a whole lot of new code, and
> I'm not sure that I see a use-case that justifies it. So I'm tempted to
> take out that particular ALTER capability altogether. I note that the
> corresponding feature of changing a dictionary's template on-the-fly
> doesn't exist (though it'd actually be a lot easier to support).
yes, here we tried to be sane
>
> Comments?
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > After starting to document this stuff I'm wondering whether it really > makes sense to change the parser associated with a tsearch > configuration. The problem is that the new parser might have an > unrelated set of token types, but we don't do anything about updating > the configuration's mappings. I'm not really up-to-date on all this tsearch stuff. What would happen if you already had a parser but wanted to fix a bug or add one new feature or something like that? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com