Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in GUC variable tsearch_conf_name. If it's not defined, then FTS
config
On Mon, 26 Mar 2007, Tom Lane wrote:
Oleg Bartunov writes:
On Fri, 23 Mar 2007, Florian G. Pflug wrote:
Isn't the real problem that only _one_ configuration per locale should
be marked as DEFAULT at any time, no matter what schema it is in?
I'm not sure I understand you correct (a bit comp
Oleg Bartunov writes:
> On Fri, 23 Mar 2007, Florian G. Pflug wrote:
>> Isn't the real problem that only _one_ configuration per locale should
>> be marked as DEFAULT at any time, no matter what schema it is in?
> I'm not sure I understand you correct (a bit complex :), but it's allowed
> to have
On Mon, 26 Mar 2007, Florian G. Pflug wrote:
Oleg Bartunov wrote:
On Fri, 23 Mar 2007, Florian G. Pflug wrote:
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default.
Oleg Bartunov wrote:
On Fri, 23 Mar 2007, Florian G. Pflug wrote:
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several
FTS configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in
On Fri, 23 Mar 2007, Florian G. Pflug wrote:
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in GUC variable tsearch_c
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in GUC variable tsearch_conf_name. If it's not defined, then FTS
config
http://www.sigaev.ru/misc/tsearch_core-0.41.gz
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Changes
1) added command
ALTER FULLTEXT MAPPING ON cfgname [FOR lexemetypename[, ...]] REPLACE
olddictname TO newdictname;
2) added operator class for text and varchar
CREATE INDEX idxname ON tblname
Robert Treat wrote:
On Friday 16 March 2007 10:45, Teodor Sigaev wrote:
I don't see how the proposal is going to solve that type of problem, but
maybe I am overlooking something?
The same way as other system tables objects, they don't dump, they don't
restore. In 8.3, seems, API to index AM wil
On Friday 16 March 2007 10:45, Teodor Sigaev wrote:
> > I don't see how the proposal is going to solve that type of problem, but
> > maybe I am overlooking something?
>
> The same way as other system tables objects, they don't dump, they don't
> restore. In 8.3, seems, API to index AM will be chang
Oleg Bartunov wrote:
On Fri, 16 Mar 2007, Joshua D. Drake wrote:
One a related note - will to_tsvector and to_tsquery be renamed to
something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
ts_ means Text Search, I don't
Florian G. Pflug wrote:
> Teodor Sigaev wrote:
>> CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
>>
>> Fulltext_ops opclass parses the document similarly to_tsvector nad
>> stores lexemes in gin index. It's a full equalent of
>> CREATE INDEX ... ( to_tsvector( textcolumn ) )
>
On Fri, 16 Mar 2007, Joshua D. Drake wrote:
One a related note - will to_tsvector and to_tsquery be renamed to
something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
ts_ means Text Search, I don't think ft_ (Full Text)
Tom Lane wrote:
Actually, if you wanted to simplify
life a bit, you could mark fulltext_ops as being the default opclass
for text (and varchar I guess) under GIST and GIN. Then it reduces
to just
CREATE INDEX idxname ON tblname USING gin (textcolumn);
Nice. This gets my vote.
cheers
and
> One a related note - will to_tsvector and to_tsquery be renamed to
> something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +
Teodor Sigaev wrote:
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
Fulltext_ops opclass parses the document similarly to_tsvector nad
stores lexemes in gin index. It's a full equalent of
CREATE INDEX ... ( to_tsvector( textcolumn ) )
And, let we define operation text @
I don't see how the proposal is going to solve that type of problem, but maybe
I am overlooking something?
The same way as other system tables objects, they don't dump, they don't
restore. In 8.3, seems, API to index AM will be changed - will anybody except
pghackers see that? New opclass layo
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Hmm, you are prompting an idea to me how to simplify usage of full text index
> in
> simple cases.
> CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
+1 ... makes the easy cases easy, doesn't make the hard cases any
harder.
> BT
On Friday 16 March 2007 04:44, Teodor Sigaev wrote:
> > I'm also concerned about the stability of the tsearch api in general wrt
> > including it in core. Currently the recommended upgrade practice is to
> > dump/reload without tsearch, installing the new servers version of
> > tsearch
>
> That is
I'm also concerned about the stability of the tsearch api in general wrt
including it in core. Currently the recommended upgrade practice is to
dump/reload without tsearch, installing the new servers version of tsearch
That is because pg_ts* tables changes, function names and internal API. Putt
Yeah, that one. It might be more consistent to spell it as "fulltext_ops"
but I wouldn't insist on it.
Hmm, you are prompting an idea to me how to simplify usage of full text index in
simple cases.
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
Fulltext_ops opclass pa
On Fri, 16 Mar 2007, Magnus Hagander wrote:
Most people whom I talk to about tsearch who want the syntax changed to make
it easier want something akin to just "CREATE INDEX fti1 on t1(c1) USING
FULLTEXT" and then be done with it. This patch isn't going to give people
that.
Since we use standa
> > Most people whom I talk to about tsearch who want the syntax changed to make
> > it easier want something akin to just "CREATE INDEX fti1 on t1(c1) USING
> > FULLTEXT" and then be done with it. This patch isn't going to give people
> > that.
>
> Since we use standard postgresql-ish CREATE IND
On Thu, 15 Mar 2007, Joshua D. Drake wrote:
And is there some another objections?
Most people whom I talk to about tsearch who want the syntax changed to make
it easier want something akin to just "CREATE INDEX fti1 on t1(c1) USING
FULLTEXT" and then be done with it. This patch isn't going
On Thu, 15 Mar 2007, Robert Treat wrote:
On Thursday 15 March 2007 12:17, Teodor Sigaev wrote:
Last try there was a fight about syntax of introduced commands. And we
(Oleg and me) developed variant of patch with another syntax. We will not
change docs until agreement will be reached, current ve
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Surely the CREATE INDEX syntax has got enough warts on it already.
>
>> Do you mean something like:
>> CREATE INDEX ftil ON t1 USING GIST|GIN(C1 FULLTEXT);
>> Where FULLTEXT is like VARCHAR OPS?
>
> Yeah, that
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely the CREATE INDEX syntax has got enough warts on it already.
> Do you mean something like:
> CREATE INDEX ftil ON t1 USING GIST|GIN(C1 FULLTEXT);
> Where FULLTEXT is like VARCHAR OPS?
Yeah, that one. It might be more consis
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> +1 (again) Although I would see something like this:
>> CREATE INDEX fti1 on t1(c1) USING FULLTEXT [WITH] GIST | GIN
>
> Surely the CREATE INDEX syntax has got enough warts on it already.
> Can't we express this as a particular ope
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> +1 (again) Although I would see something like this:
> CREATE INDEX fti1 on t1(c1) USING FULLTEXT [WITH] GIST | GIN
Surely the CREATE INDEX syntax has got enough warts on it already.
Can't we express this as a particular operator class, or something
>> And is there some another objections?
>
> Most people whom I talk to about tsearch who want the syntax changed to make
> it easier want something akin to just "CREATE INDEX fti1 on t1(c1) USING
> FULLTEXT" and then be done with it. This patch isn't going to give people
> that.
+1 (again)
On Thursday 15 March 2007 12:17, Teodor Sigaev wrote:
> Last try there was a fight about syntax of introduced commands. And we
> (Oleg and me) developed variant of patch with another syntax. We will not
> change docs until agreement will be reached, current version
> http://mira.sai.msu.su/~megera/
Last try there was a fight about syntax of introduced commands. And we (Oleg and
me) developed variant of patch with another syntax. We will not change docs
until agreement will be reached, current version
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Following demonstrates subset of FTS syntax
32 matches
Mail list logo
