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  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: preserving forensic information when we freeze
Следующее
От: Bernd Helmle
Дата:
Сообщение: Re: Fixing pg_basebackup with tablespaces found in $PGDATA