From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Last call for comments: fmgr rewrite [LONG] |
Date: | 2000-05-22 03:46:22 |
Message-ID: | 3928AD8E.9ADCB89B@nimrod.itg.telecom.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> No, because we aren't ever going to be dynamically allocating these
> things; they'll be local variables in the calling function.
Fair enough then. Although that being the case, I don't see the big deal
about using a few more bytes of stack space which costs absolutely
nothing, even though the binary compatibility is a small but still real
advantage.
> >>>> Wondering if some stub code generator might be appropriate so that
> >>>> functions can can continue to look as readable as before?
> >>
> >> Er, did you read to the end of the proposal?
>
> > Yep. Did I miss your point?
>
> Possibly, or else I'm missing yours. What would a stub code generator
> do for us that the proposed GETARG and RETURN macros won't do?
Only that it might be slightly cleaner code, but you're probably right.
I just have experience doing this sort of thing and know that manually
grabbing each argument can be painful with hundreds of functions.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-22 04:08:20 | Re: Last call for comments: fmgr rewrite [LONG] |
Previous Message | Tom Lane | 2000-05-22 03:28:31 | Re: Last call for comments: fmgr rewrite [LONG] |