Re: tsearch in core patch, for inclusion - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: tsearch in core patch, for inclusion
Date
Msg-id BAY20-F238A6DCE6F35B45DC0F50EF98F0@phx.gbl
Whole thread Raw
In response to tsearch in core patch, for inclusion  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: tsearch in core patch, for inclusion  (Markus Schiltknecht <markus@bluegap.ch>)
List pgsql-hackers
>    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/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: XLOG_NO_TRAN and XLogRecord.xl_xid
Next
From: Markus Schiltknecht
Date:
Subject: Re: tsearch in core patch, for inclusion