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]  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Last call for comments: fmgr rewrite [LONG]  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Last call for comments: fmgr rewrite [LONG]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Last call for comments: fmgr rewrite [LONG]