lztext and parser - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject lztext and parser
Date
Msg-id m11qmTx-0003kGC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
Responses Re: [HACKERS] lztext and parser  (Karel Zak - Zakkr <zakkr@zf.jcu.cz>)
List pgsql-hackers
Hi,

    I'm hacking in the operator functions for the lztext type and
    have a little question.

    With the generic per-byte decompressor I added, it  would  be
    very easy to produce functions like

        bool lztext_text_eq(lztext, text)
        bool text_lztext_eq(text, lztext)

    too.  Comparision  between  lztext and text does already work
    because there  are  lztext->text  and  vice  versa  functions
    available and the parser automatically typecasts.

    So  would  it  be a win or a dead end street to provide those
    functions?  Does it look for a  direct  comparision  function
    allways  first?  Then  it  would  be,  because it would never
    choose to  compress  the  text  item  and  then  compare  two
    lztext's (what would be terrible).


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) #

pgsql-hackers by date:

Previous
From: Keith Parks
Date:
Subject: run_check problem
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Cache on pg_statistics