| 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: | Whole Thread | Raw Message | 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
| 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 |