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 по дате отправления: