Re: more psprintf() use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: more psprintf() use
Date: 2014-01-05 20:41:49
Message-ID: 31344.1388954509@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 1/2/14, 9:28 AM, Tom Lane wrote:
>> 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.

> Well, that seems kind of dangerous. The next guys is going to write an
> extension that is returning string constants directly, and there is no
> straightforward way to detect this problem. Perhaps we should have some
> mode similar to the CLOBBER and COPY_*_TREES symbols to force a pfree()
> in assertion-enabled builds?

Seems kinda backwards. If we want to put any effort into this issue,
it'd be better to head in the direction of making the world safe for
output functions to return constants, ie deprecate rather than enforce
the practice of pfree'ing their results. But see
http://www.postgresql.org/message-id/12646.1383420576@sss.pgh.pa.us

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-05 20:45:20 Re: [PATCH] Store Extension Options
Previous Message Emre Hasegeli 2014-01-05 20:36:08 Re: GiST support for inet datatypes