Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
От | Tom Lane |
---|---|
Тема | Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |
Дата | |
Msg-id | 25868.1357749466@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PATCH] unified frontend support for pg_malloc et al
and palloc/pfree mulation (was xlogreader-v4)
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2013-01-09 13:46:53 +0200, Heikki Linnakangas wrote: >> I don't understand the need for this change. Can't you just: >> #define palloc(s) pg_malloc(s) >> in the frontend context? > Yes, that would be possible, but imo its the inferior solution: I'm with Heikki: in fact, I will go farther and say that this approach is DOA. The only way you get to change the backend's definition of palloc is if you can show that doing so yields a performance boost in the backend. Otherwise, we use a macro or whatever is necessary to allow frontend code to have a different underlying implementation of palloc(x). > * it precludes ever sharing code without compiling twice That's never going to happen anyway, or at least there are plenty more problems in the way of it. > * removing allows us to get rid of the following ugliness in dirmod.c: I agree that what dirmod is doing is pretty ugly, but it's localized enough that I don't care particularly. (Really, the only reason it's a hack and not The Solution is that at the moment there's only one file doing it that way. A trampoline function for use only by code that needs to work in both frontend and backend isn't an unreasonable idea.) regards, tom lane
В списке pgsql-hackers по дате отправления: