Re: Last call for comments: fmgr rewrite [LONG]
От | Tom Lane |
---|---|
Тема | Re: Last call for comments: fmgr rewrite [LONG] |
Дата | |
Msg-id | 11675.958954577@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Last call for comments: fmgr rewrite [LONG] (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>) |
Список | pgsql-hackers |
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes: > Just wondering what the implications of FUNC_MAX_ARGS is, and whether > something like... > struct FuncArg > { > Datum arg; > bool argnull; > }; I did consider that but it's probably not worth near-doubling the size of the struct (think about how that will pack, especially if Datum becomes 8 bytes). The average callee will probably not be looking at the argnull array at all, so it won't have a dependency on the offset to argnull in the first place. Furthermore FUNC_MAX_ARGS is not going to vanish in the foreseeable future; we have fixed-size arrays in places like pg_proc and there's just not enough reason to go to the pain of making those variable-size. So the only possible win would be to make dynamically loaded functions binary-compatible across installations with varying FUNC_MAX_ARGS values ... and since that'd matter only if they looked at argnull *and* not at any other structure that depends on FUNC_MAX_ARGS, it's probably not worth it. > 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? regards, tom lane
В списке pgsql-hackers по дате отправления: