Re: more psprintf() use
От | Tom Lane |
---|---|
Тема | Re: more psprintf() use |
Дата | |
Msg-id | 27309.1388672899@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: more psprintf() use (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: more psprintf() use
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-01-02 09:49:48 +0200, Heikki Linnakangas wrote: >> Is it legal to return a constant with PG_RETURN_CSTRING? Grepping around, I >> don't see that being done anywhere else, but there are places that do >> PG_RETURN_CSTRING(pstrdup(<constant>))... > I don't see why it wouldn't be legal - constant strings have static > storage duration, i.e. the program lifetime. And I can see nothing that > would allow pfree()ing the return value of cstring returning functions > in the general case. Heikki is right and you are wrong. There is an ancient supposition that datatype output functions, in particular, always return palloc'd strings. I recently got rid of the pfree's in the main output path, cf commit b006f4ddb988568081f8290fac77f9402b137120, which might explain why this patch passes regression tests; but there are still places in the code (and even more likely in third-party code) that will try to pfree the results. So -1 for this particular change. The pstrdup that Heikki suggests would be safer practice. regards, tom lane
В списке pgsql-hackers по дате отправления: