Re: DTrace probe patch for OS X Leopard
От | Robert Lor |
---|---|
Тема | Re: DTrace probe patch for OS X Leopard |
Дата | |
Msg-id | 47C83CB2.7040306@sun.com обсуждение исходный текст |
Ответ на | Re: DTrace probe patch for OS X Leopard (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DTrace probe patch for OS X Leopard
Re: DTrace probe patch for OS X Leopard |
Список | pgsql-patches |
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > >> Hmm, so let's have a third file that's not autogenerated, which is the >> file we will use for #includes, and contains just that block. >> > > Or just two files. Call probes_null something else, have it be included > where needed, have it include the autogenerated file when appropriate. > > I really like this idea. So, we're now back to having pg_trace.h which includes the autogenerated probes.h when Dtrace is enabled, else null macros will be used. Currently, pg_trace.h is included in c.h, and I feel strongly that it should remains there because by design I'd like to 1) have the tracing feature be available both in the frontend and backend without having to do anything extra, which also means that probes.h needs to be generated before any compilation 2) centralize the include of this header just in case the implementation needs to be changed for some reason (eg, if this file needs to be splitted, etc) 3) reduce the number of changes to a minimal when adding new probes to new .c files I haven't heard any major disadvantages about keeping it in c.h, but if you are still adamant about keeping it out of c.h, I'll will go along with that. Regards, -Robert
В списке pgsql-patches по дате отправления: