| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | 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:25:57 |
| Message-ID: | 52C9BFD5.6080903@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2014-01-05 20:30:27 | Re: more psprintf() use |
| Previous Message | Peter Eisentraut | 2014-01-05 20:16:21 | Re: [PATCH] SQL assertions prototype |