Re: Better testing coverage and unified coding for plpgsql loops
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Better testing coverage and unified coding for plpgsql loops |
| Дата | |
| Msg-id | 22954.1515008222@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Better testing coverage and unified coding for plpgsql loops (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> I really think we should stick with the macro implementation, unless
>> somebody wants to do some actual investigation to prove that a
>> function implementation imposes negligible cost.
> I don't really care too much about the macro-or-function side of this,
> but if you wanted to improve debuggability avoiding the performance cost
> of a function call, you could use a static inline function, which is
> supposed (AFAIK) to have performance characteristics equivalent to those
> of a macro.
I'm not sure whether inlining the function can be relied on to get rid
of the side effects of taking rc's address. It wouldn't take all that
much work to establish the point, probably, but it's work I don't care
to put into it.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера