Re: Coping with 'C' vs 'newC' function language names
От | Tom Lane |
---|---|
Тема | Re: Coping with 'C' vs 'newC' function language names |
Дата | |
Msg-id | 13119.974479932@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Coping with 'C' vs 'newC' function language names (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Coping with 'C' vs 'newC' function language names
Re: Coping with 'C' vs 'newC' function language names |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > Couldn't the function handler detoast the values before handing them to > the function? That would be slower, but it would allow people to continue > to use the "simpler" interface. This would be a moderately expensive thing to do --- not impossible, but relatively expensive. The old-style function handler would need to look up all the function-argument datatypes during fmgr_info() so that it could save a bool array telling it which argument positions need detoasting. (You can't just detoast every Datum --- you have to at least verify that it's of a varlena type first.) On a per-invocation basis, however, it probably wouldn't be very costly. I didn't want to do this during development, but now that there are no more old-style internal functions left, I suppose you could make a good argument that this is worth doing for old-style dynamically loaded functions. Will put it on the to-do list. Are people satisfied with the notion of requiring an info function to go with each dynamically loaded new-style function? If so, I'll start working on that too. regards, tom lane
В списке pgsql-hackers по дате отправления: