On 2013-01-09 11:37:46 -0500, Tom Lane wrote: > Andres Freund <and...@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).
Whats the usecase for being able to redefine it after the patch? Its not like you can do anything interesting given that pfree() et. al. is not a macro. > > * 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.) Well, after the patch the trampoline function would be palloc() itself. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
