From: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> |
---|---|
To: | teodor(at)sigaev(dot)ru |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tsearch in core patch, for inclusion |
Date: | 2007-02-22 16:18:19 |
Message-ID: | BAY20-F238A6DCE6F35B45DC0F50EF98F0@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2007-02-22 16:20:18 | Re: Column storage positions |
Previous Message | Tom Lane | 2007-02-22 16:11:35 | Re: XLOG_NO_TRAN and XLogRecord.xl_xid |