Bruce Momjian <br...@momjian.us> writes:
> On Fri, Feb 14, 2014 at 11:28:49PM -0500, Tom Lane wrote:
>> The first and third hunks look to me like they introduce memory
>> leaks, not fix them. The second hunk is probably safe enough,
Advertising
> The first and third just move the free into blocks where we have already
> tested the value is not null. It just more clearly matches the
> surrounding code. Do you see something different?
[ looks closer... ] OK, they're not actually broken, but I question
whether they're improvements. The existing coding is clear enough
that the result of psql_scan_slash_option will be freed. What you're
doing is conflating that requirement with some other processing.
>> although I'm not sure the case can actually occur --- gset should
>> free the prefix before any new backslash command can be executed.
> Oh, interesting idea. Updated patch attached.
I don't think that's an improvement at all. My point was that I
didn't think gset_prefix would ever be set at entry to this code,
because the setting should never survive for more than one backslash
command execution cycle.
If you want to add probably-useless code to free it, go ahead, but
this isn't a clearer way to do that than your previous version.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
