Re: texteq/byteaeq: avoid detoast [REVIEW]

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: texteq/byteaeq: avoid detoast [REVIEW]
Дата
Msg-id AANLkTimW_=tSVrMCygOY5Nf36jf-Y-jpV=VK0gjDVxFo@mail.gmail.com
обсуждение исходный текст
Ответ на Re: texteq/byteaeq: avoid detoast [REVIEW]  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: limiting hint bit I/O
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: READ ONLY fixes