Re: Text <-> C string

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Gregory Stark wrote:
>> "Tom Lane" <tgl@sss.pgh.pa.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