Re: [rfc,patch] PL/Proxy in core - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: [rfc,patch] PL/Proxy in core
Date
Msg-id e51f66da0805150728g2d785cdep7d0686661d5c03b1@mail.gmail.com
Whole thread Raw
In response to Re: [rfc,patch] PL/Proxy in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [rfc,patch] PL/Proxy in core  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5/15/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
> > How about following patch?  I have bison 2.3 and it seems not to do
>  > global allocation, so it should be fine.  There may be early exit
>  > with elog(ERRROR) inside so I'd like to avoid malloc() itself.
>
> None of our other parsers fool with bison's memory allocation;
>  why does yours need to?

Because that way I can be sure I understand their allocation behaviour.

Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
I don't understand it.

But if I force them use palloc(), always, I can be sure memore is freed.

-- 
marko


pgsql-hackers by date:

Previous
From: pgsql@mohawksoft.com
Date:
Subject: Re: SSL and USER_CERT_FILE
Next
From: Bernd Helmle
Date:
Subject: Adding variables for segment_size, wal_segment_size and block sizes