Reece Hart <reece@harts.net> 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
