|From:||Teodor Sigaev <teodor(at)sigaev(dot)ru>|
|To:||Jeff Davis <pgsql(at)j-davis(dot)com>|
|Cc:||Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Prefix support for synonym dictionary|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 1. The docs should be clarified a little. For instance, it should have a
> link back to the definition of a prefix search (12.3.2). I included my
> doc suggestions as an attachment.
Thank you, merged
> 2. dsynonym_init() uses findwrd() in a slightly confusing (and perhaps
> fragile) way. After calling findwrd(), the "end" pointer is pointing at
> either the end of the string, or the *; depending on whether the string
> ends in * and whether flags is NULL. I only mention this because I had
> to take a more careful look to see what was happening. Perhaps add a
> comment to make it more clear?
* Finds the next whitespace-delimited word within the 'in' string.
* Returns a pointer to the first character of the word, and a pointer
* to the next byte after the last character in the word (in *end).
* Character '*' at the end of word will not be threated as word
* charater if flags is not null.
static char *
findwrd(char *in, char **end, uint16 *flags)
> 3. The patch looks for the special byte '*'. I think that's fine,
> because we depend on the files being in UTF-8 encoding, where it's the
> same byte. However, I thought it was worth mentioning in case we want to
> support other encodings for text search files later.
tsearch_readline() converts file's UTF8 encoding into server encoding. pgsql
supports only encoding which are a superset of ASCII. So it's safe to use
asterisk with any encodings
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
|Next Message||Robert Haas||2009-08-06 16:19:51||Re: Prefix support for synonym dictionary|
|Previous Message||David Fetter||2009-08-06 15:44:28||Re: dblink bulk operations|