Gregory Stark <stark@enterprisedb.com> writes: > Ok, this removes what should be most if not all of the call sites where we're > detoasting text or byteas. In particular it gets all the regexp/like functions > and all the trim/pad functions. It also gets hashtext and hash_any. Applied with some fixes --- you'd missed like_match.c, which doubtless explains Guillame's complaint that it didn't work ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Brendan Jurd" <direvus@gmail.com> writes: > On 9/22/07, Gregory Stark <stark@enterprisedb.com> wrote: >> Ok, this removes what should be most if not all of the call sites where we're >> detoasting text or byteas. In particular it gets all the regexp/like functions >> and all the trim/pad functions. It also gets hashtext and hash_any. > Looks like there's some more of this in src/tutorial/funcs.c and funcs_new.c. Well, those are just tutorial code, so I'd vote for keeping it simple. > On a related note, while I was trawling through header files trying to > wrap my head around all this toast and varlena business, I found the > following comment, in fmgr.h and reiterated in postgres.h: > WARNING: It is only safe to use PG_DETOAST_DATUM_UNPACKED() and > VARDATA_ANY() if you really don't care about the alignment. > Shouldn't this be PG_DETOAST_DATUM_PACKED()? Yup, good catch. In the context of fmgr.h, it seems like the comment is more sensible if it refers to the underlying function pg_detoast_datum_packed (which is what the preceding paragraph is speaking of), so I made it say that instead. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings