Re: texteq/byteaeq: avoid detoast [REVIEW] - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: texteq/byteaeq: avoid detoast [REVIEW]
Date
Msg-id AANLkTimW_=tSVrMCygOY5Nf36jf-Y-jpV=VK0gjDVxFo@mail.gmail.com
Whole thread Raw
In response to Re: texteq/byteaeq: avoid detoast [REVIEW]  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
2011/1/16 Noah Misch <noah@leadboat.com>:
> On Sun, Jan 16, 2011 at 10:07:13PM +0100, Pavel Stehule wrote:
>> I think, so we can have a function or macro that compare a varlena
>> sizes. Some like
>>
>> Datum texteq(..)
>> {
>>      if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
>>         PG_RETURN_FALSE();
>>
>>      ... actual code ..
>> }
>
> Good point.  Is this something that would be useful many places?  One thing that
> bugged me slightly writing this patch is that texteq, textne, byteaeq and
> byteane all follow the same pattern rather tightly.  (Indeed, I think one could
> easily implement texteq and byteaeq with the exact same C function.).

It isn't good idea. Theoretically, there can be differencies between
text and bytea in future - there can be important collations. Now,
these types are distinct and some basic methods should be distinct
too. Different situation is on varlena level.

Regards

Pavel Stehule

I like how
> we handle this for tsvector (see TSVECTORCMPFUNC in tsvector_op.c) to avoid the
> redundancy.  If datumHasSameLength would mainly apply to these four functions or
> ones very similar to them, maybe we should abstract out the entire function body
> like we do for tsvector?
>
> A topic for a different patch in any case, I think.
>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: limiting hint bit I/O
Next
From: Jeff Janes
Date:
Subject: Re: READ ONLY fixes