SEO

> CREATE FULLTEXT CONFIGURATION myfts LIKE template_cfg AS DEFAULT;
> SELECT add_fulltext_config('myfts', 'template_cfg', True);

>That's simple, but what about
>CREATE FULLTEXT MAPPING ON cfgname FOR lexemetypename[, ...] WITH
>dictname1[, ...];
>?
>
>SELECT create_fulltext_mapping(cfgname, '{lexemetypename[, ...]}'::text[],
> '{dictname1[, ...]}'::text[]);
>
>Seems rather ugly for me...

Functions maybe doesn't see efective, but user's cannot learn new syntax.

SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'], ARRAY['...'])
is readable.

I agree so enhancing parser oabout not standard construct isn't good.

>And function interface does not provide autocompletion and online help in
>psql. \df says only types of arguments, not a meaning.

Yes, I miss better support function in psql too. But it's different topic. I
don't see reason why
\h cannot support better functions.

Nice a day
Pavel Stehule

__________________________________________________ _______________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Hi,

Pavel Stehule wrote:
> Functions maybe doesn't see efective, but user's cannot learn new syntax.

Are you serious? That argument speaks exactly *for* extending the
grammar. From other databases, users are used to:

CREATE TABLE ... (SQL)
CREATE INDEX ... (SQL)
CREATE FULLTEXT INDEX ... (Transact-SQL)
CREATE TABLE (... FULLTEXT ...) (MySQL)
CREATE INDEX ... INDEXTYPE IS ctxsys.context PARAMETERS ... (Oracle Text)

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:

- it's counter-intuitive to have to SELECT, when you want to CREATE
something.
- it's confusing to have two actions (select create)
- why do I have to write ARRAYs to list parameters?
- it's not obvious what you're selecting (return value?)
- you have to keep track of the brackets, which can easily get messed
up with two levels of them. Especially if the command gets multiple
lines long.

> I agree so enhancing parser oabout not standard construct isn't good.

Generally? Wow! This would mean PostgreSQL would always lack behind
other RDBSes, regarding ease of use. Please don't do that!

Regards

Markus


---------------------------(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
match

>
> 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.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> > 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/


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Pavel Stehule wrote:
>> > 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.

I am not talking about stored procedures. I am talking about a very
ugly, counter intuitive syntax above.

Initializing full text should be as simple as:

CREATE INDEX foo USING FULLTEXT(bar);

(or something similar)

Or:

CREATE TABLE foo (id serial, names text FULLTEXT);

Anything more complicated is a waste of cycles.

Joshua D. Drake



--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

>I am not talking about stored procedures. I am talking about a very
>ugly, counter intuitive syntax above.
>
>Initializing full text should be as simple as:
>
>CREATE INDEX foo USING FULLTEXT(bar);
>
>(or something similar)
>
>Or:
>
>CREATE TABLE foo (id serial, names text FULLTEXT);
>
>Anything more complicated is a waste of cycles.
>
>Joshua D. Drake

I agree. Question: what about multilanguage fulltext.

CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
CREATE TABLE foo (id serial, names text FULLTEXT [ (czech_dictionary,
english_dictionary) ] );

all others can we do via SP.

Pavel Stehule

__________________________________________________ _______________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/


---------------------------(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
match

>> CREATE TABLE foo (id serial, names text FULLTEXT);
>>
>> Anything more complicated is a waste of cycles.
>>
>> Joshua D. Drake
>
> I agree. Question: what about multilanguage fulltext.
>
> CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
> CREATE TABLE foo (id serial, names text FULLTEXT [ (czech_dictionary,
> english_dictionary) ] );
>
> all others can we do via SP.

That works for me with perhaps a default mapping to locales? For example
if our locale is en_us.UTF8 we are pretty assured that we are using english.

Joshua D. Drake



>
> Pavel Stehule
>
> __________________________________________________ _______________
> Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
> http://www.msn.cz/
>
>
> ---------------------------(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
> match
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

>
> >> CREATE TABLE foo (id serial, names text FULLTEXT);
> >>
> >> Anything more complicated is a waste of cycles.
> >>
> >> Joshua D. Drake
> >
> > I agree. Question: what about multilanguage fulltext.
> >
> > CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
> > CREATE TABLE foo (id serial, names text FULLTEXT [ (czech_dictionary,
> > english_dictionary) ] );
> >
> > all others can we do via SP.
>
>That works for me with perhaps a default mapping to locales? For example
>if our locale is en_us.UTF8 we are pretty assured that we are using
>english.
>

90% yes. 10% no. In czech typical task: find word without accents, or find
german, english, czech stemmed word in multilanguage documents (or different
languages depend on topology). Lot of databases are minimal bilanguagal (in
czech rep. german and czech).

Pavel

p.s. missing collates is big minus for PostgreSQL in eu (we have some
workarounds)

__________________________________________________ _______________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Am Donnerstag, 22. Februar 2007 18:07 schrieb Markus Schiltknecht:
> > I agree so enhancing parser oabout not standard construct isn't good.
>
> Generally? Wow! This would mean PostgreSQL would always lack behind
> other RDBSes, regarding ease of use. Please don't do that!

You are confusing making a full-text index and configuring the full-text
engine. Tsearch already gives you a standard CREATE INDEX variant to do the
former. The discussion here is about the latter, and notably Oracle uses
functions there.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings