Re: get_progname() should not be const char *? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: get_progname() should not be const char *?
Date
Msg-id 6772.1360167761@sss.pgh.pa.us
Whole thread Raw
In response to Re: get_progname() should not be const char *?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: get_progname() should not be const char *?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 5, 2013 at 12:18 AM, Phil Sorber <phil@omniti.com> wrote:
>> On Mon, Feb 4, 2013 at 10:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I don't believe that callers should be trying to free() the result.
>>> Whether it's been strdup'd or not is not any of their business.

>> Is that just because of the nature of this specific function?

> I can't presume to speak for Tom, but I think so.  Sometimes the API
> of a function includes the notion that the caller should pfree the
> result.  Sometimes it doesn't.  The advantage of NOT including that in
> the API contract is that you can sometimes do optimizations that would
> be impossible otherwise - e.g. you can return the same palloc'd string
> on successive calls to the function; or you can sometimes return a
> statically allocated string.

Yeah.  In this particular case, it seems rather obvious that the
function should be returning the same string each time --- if it's
actually doing a fresh malloc, that sounds like a bug.

But in any case, adding or removing a const qualifier from a function's
result typically goes along with an API-contract change as to whether
the caller is supposed to free the result or not.  My objection here
was specifically that I don't believe the contract for get_progname
includes caller-free now, and I don't want it to start being that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: sql_drop Event Trigger
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system