Re: [HACKERS] lztext.c

Tatsuo Ishii wrote:

> I'm going to commit changes to make lztextlen() aware of
> multi-byte. While doing the work, I found that no POSITION() or
> SUBSTRING() for lztext has been implemented in the file.

    Thank's  for  that.  I  usually don't have multi-byte support
    compiled in and it's surely better if you  do  the  extension
    and tests.

    I know that a lot of functions are missing so far. Especially
    comparision and the mentioned ones. I thought to get back  on
    it after the multi-byte support is inside.

> BTW, does anybody work on making lztext indexable?  If no, I will take
> care of it with above addtions.

    IMHO something questionable.

    A compressed data type is preferred to store large amounts of
    data.  Indexing large fields OTOH is something to prevent  by
    database  design.   The  new  type  at hand offers reasonable
    compression rates only above some size of input.

    OTOOH, it might get someone around the btree  split  problems
    some of us encountered and which I where able to trigger with
    field contents above 2K already. In such a case it can  be  a
    last resort.

    I'd like to know what others think.

    Don't  spend  much efford for comparision and the SUBSTRING()
    things right now. I already have an  additional,  generalized
    decompressor in mind, that can be used in the comparision for
    example  to  decompress  two  values  on  the  fly  and  stop
    comparision  at  the  first difference, which usually happens
    early in two random datums.

    Tell me when you have the multi-byte  (and  maybe  cyrillic?)
    stuff committed and I'll take my hands back on the code.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #