| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: more psprintf() use |
| Date: | 2014-01-02 14:28:19 |
| Message-ID: | 27309.1388672899@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bernd Helmle | 2014-01-02 14:34:04 | Re: Fixing pg_basebackup with tablespaces found in $PGDATA |
| Previous Message | Dimitri Fontaine | 2014-01-02 13:06:32 | Re: Fixing pg_basebackup with tablespaces found in $PGDATA |