From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org (PostgreSQL HACKERS) |
Subject: | lztext and parser |
Date: | 1999-11-25 00:09:53 |
Message-ID: | m11qmTx-0003kGC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-11-25 00:21:07 | Re: [HACKERS] Cache on pg_statistics |
Previous Message | Keith Parks | 1999-11-24 23:37:43 | run_check problem |