Tom Lane wrote:
> Something that was annoying me yesterday was that it was not clear
> whether we had fixed every single place that uses a tsearch config file
> to assume that the file is in UTF8 and should be converted to database
> encoding. So I was thinking of hardwiring the "recode" part into
On Thu, 23 Aug 2007, Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
- readstopwords calls recode_and_lowerstr directly, instead of using the
"wordop" function pointer in StopList struct. All callers used
recode_and_lowerstr anyway, so this simplifies the code a little bit. Is
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> The fix should be in combo_decrypt() because other code
> should not need to guess whether zero-length input is
> allowed or not.
> Patch attached.
Thanks -- applied in all branches back to 7.3.
regards, tom lane
--
Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> - readstopwords calls recode_and_lowerstr directly, instead of using the
>> "wordop" function pointer in StopList struct. All callers used
>> recode_and_lowerstr anyway, so this simplifies the code a little bit. Is
>> there any
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> - readstopwords calls recode_and_lowerstr directly, instead of using the
> "wordop" function pointer in StopList struct. All callers used
> recode_and_lowerstr anyway, so this simplifies the code a little bit. Is
> there any external dictionary im
Fixes the following bugs:
- ispell initialization crashed on empty dictionary file
- ispell initialization crashed on affix file with prefixes but no suffixes
- stop words file was ran through pg_verify_mbstr, with database
encoding, but it's later interpreted as being UTF-8. Now verifies that
it's
On 8/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ken Colson" <[EMAIL PROTECTED]> writes:
> > this statement:
> > select decrypt(''::bytea,'password','bf')
> > causes the postgresql backend to crash:
> > This seems to be a 64bit problem.
>
> Reproduced here in HEAD. The problem is here:
> 293
