Re: [rfc,patch] PL/Proxy in core

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [rfc,patch] PL/Proxy in core
Date: 2008-05-15 14:28:28
Message-ID: e51f66da0805150728g2d785cdep7d0686661d5c03b1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/15/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Marko Kreen" <markokr(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2008-05-15 14:56:23 Adding variables for segment_size, wal_segment_size and block sizes
Previous Message pgsql 2008-05-15 14:25:09 SSL and USER_CERT_FILE round 2