Re: tsearch in core patch, for inclusion
От | Pavel Stehule |
---|---|
Тема | Re: tsearch in core patch, for inclusion |
Дата | |
Msg-id | BAY20-F5255F11404D8D5A21655DF98F0@phx.gbl обсуждение исходный текст |
Ответ на | Re: tsearch in core patch, for inclusion ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: tsearch in core patch, for inclusion
|
Список | pgsql-hackers |
> > And users are constantly complaining that PostgreSQL doesn't have > > fulltext indexing capabilities (if they don't know about tsearch2) or > > about how hard it is to use tsearch2. > > > >> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'], > >> ARRAY['...']) is readable. > > > > Hardly. Because it's not like SQL: > >I have to agree here. > >SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'], >ARRAY['...']) is readable. > >Is a total no op. We might as well just leave it in contrib. > I am for integration tsearch to core, why not. But I don't see reason for special syntax. Stored procedures is exactly good tool for it. Fulltext is standarised in SQL/MM, SQL Multimedia and Application Packages, Part 2: Full-Text Why implement extensive proprietary solution? If our soulution is proprietary, then so it is simple and cheap and doesn't complicate future conformance with ANSI SQL. Regards Pavel Stehule _________________________________________________________________ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
В списке pgsql-hackers по дате отправления: