Re: Text <-> C string

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Gregory Stark wrote:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> If there are not additional votes, I'll go with TextPGetCString
>>> and CStringGetTextP.
>>
>> I would have voted for text_to_cstring etc. I can see the logic for the above
>> but it's just such a pain to type...

> +1 for text_to_cstring et al.

Well, that's all right with me too.

It occurs to me that this proposal is still leaving something on the
table. Consider a SQL-callable function that takes a text argument and
wants to turn it into a C string for processing. With the proposal as
it stands you'd have to do something like

text *t = PG_GETARG_TEXT_P(0);
char *c = text_to_cstring(t);

Now you might be smart enough to optimize that to

text *t = PG_GETARG_TEXT_PP(0);
char *c = text_to_cstring(t);

which would avoid a useless copy for short-header text datums, but it's
still leaking an extra copy of the text if the input is compressed or
toasted out-of-line. I'm imagining instead

char *c = PG_GETARG_TEXT_AS_CSTRING(0);

This would expand to a call on say text_datum_to_cstring(Datum d)
which would detoast, convert, and then free the detoasted copy if
needed.

On the other hand, it could be argued that this is usually a waste of
effort. (I frequently point out to people that retail pfree's in
SQL-callable functions are often less efficient than letting the next
context reset clean up.) And one thing I don't like about this notation
is that the declared type of the local variable no longer matches up
with the SQL-level declaration of the function.

Comments anyone?

regards, tom lane