Reece Hart <reece@xxxxxxxxx> writes: > On Mon, 2006-08-14 at 11:27 -0400, Tom Lane wrote: >> The usual way to get a C string from a TEXT datum is to call textout, >> eg >> str = DatumGetCString(DirectFunctionCall1(textout, datumval)); > Yikes! I've been accessing VARDATA text data like Michael for years > (code below). I account for length and don't expect null-termination, > but I don't use anything like Tom's suggestion above. Sure, that works. The problem with what Michael was doing was that he was passing the string to elog, which expects a null-terminated string. Possibly I should have written "usual way to get a null-terminated string" above, just to be clear. > 1) I based everything I did on examples lifted nearly verbatim from a > 7.x manual, and I bet Michael did similarly. I've never heard of > DatumGetCString, DirectFunctionCall1, or textout. Are these and other > treasures documented somewhere? Whose 7.x manual? This stuff has been there since we invented the "version 1" function call convention, which was 7.3 or before. There is some documentation in the SGML docs, but really we kind of expect you to look at the standard built-in functions to see how things are done... > 2) Does DatumGetCString(DirectFunctionCall1(textout, datumval)) do > something other than null terminate a string? At the moment that's all it does ... assuming that you've already detoasted the text datum ... but it's not impossible that someday it will do something different. For instance, sooner or later we are going to support multiple locales/encodings within a single database, and I wouldn't be surprised if that involves sticking extra data into text values. So it's best not to assume that you know what is inside a text datum, if possible, > 3) Is there any reason to believe that the code below is problematic? The only thing I'd suggest is that checking for a null return from palloc is a waste of effort. It doesn't return to you if it runs out of memory. regards, tom lane
