Re: Lack of Sanity Checking in file 'pctcl.c' for PostgreSQL 9.4.x - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Lack of Sanity Checking in file 'pctcl.c' for PostgreSQL 9.4.x
Date
Msg-id CAB7nPqSE2vmAdrv0LWBKkM-uBntscU6vdRRhUmKTOwjLNhJ7Lg@mail.gmail.com
Whole thread Raw
In response to Re: Lack of Sanity Checking in file 'pctcl.c' for PostgreSQL 9.4.x  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Lack of Sanity Checking in file 'pctcl.c' for PostgreSQL 9.4.x
List pgsql-bugs
On Sat, Jun 13, 2015 at 12:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Michael Paquier wrote:
>>> By the way, your patch does not compile properly and is not in-line
>>> with the project's code format. See the updated patch attached ;)
>
>> ... or the conventions for allocating memory.  Why not just use palloc()?
>
> That's hardly the fault of the proposed patch.  But yeah, it seems like
> much the best fix here is to get rid of the malloc (and strdup) calls in
> this code in favor of using the palloc infrastructure.  Even the calls
> that *do* have manual failure checks are not compliant with our usual
> coding standards.

Hm. Regarding the code path mentioned by Bill something like the patch
attached is enough with a memory context for the query description.
Now, perhaps we could do more efforts with prodesc as well, see for
example compile_pltcl_function for pltcl and similarly for plperl.
Thoughts?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: cathi.soule@roberthalf.com
Date:
Subject: BUG #13438: Restore using GUI client - Data Not Loading
Next
From: Tom Lane
Date:
Subject: Re: BUG #13438: Restore using GUI client - Data Not Loading