lztext and parser

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

Responses

Browse pgsql-hackers by date

  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