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