| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: WIP: pl/pgsql cleanup |
| Date: | 2005-02-08 00:22:15 |
| Message-ID: | 1231.1107822135@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Mon, 2005-02-07 at 10:41 -0500, Tom Lane wrote:
>> My recollection is that I was not nearly as worried about short-term
>> pallocs in the plpgsql code itself, as about leakage in various main-
>> backend routines that get called incidentally during parsing.
> Hmmm. What about switching the CurrentMemoryContext to the function's
> long-lived context when we invoke plpgsql_yyparse(), but keeping it as
> the short-lived context during the rest of the compilation process?
Doesn't plpgsql_yyparse cover pretty much all of it? IIRC, a lot of
code in pl_comp.c is called from either the lexing or parsing code.
It's not nearly as well compartmentalized as in the main SQL parser :-(
What might work is to run in the function context as the basic state,
but switch to a short-term context when calling any main-backend code
from pl_comp.c. I'm not sure how many such calls there are, but if it's
not more than a dozen or two then this wouldn't be horridly painful.
(he says, knowing *he* doesn't have to do it...)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2005-02-08 01:00:25 | Re: WIP: pl/pgsql cleanup |
| Previous Message | Neil Conway | 2005-02-07 23:56:55 | Re: WIP: pl/pgsql cleanup |