Alvaro Herrera <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> "Tom Lane" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers