Re: Last call for comments: fmgr rewrite [LONG]
От | Chris Bitmead |
---|---|
Тема | Re: Last call for comments: fmgr rewrite [LONG] |
Дата | |
Msg-id | 3928AD8E.9ADCB89B@nimrod.itg.telecom.com.au обсуждение исходный текст |
Ответ на | Last call for comments: fmgr rewrite [LONG] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Last call for comments: fmgr rewrite [LONG]
Re: Last call for comments: fmgr rewrite [LONG] |
Список | 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.
В списке pgsql-hackers по дате отправления: