Re: DTrace probe patch for OS X Leopard - Mailing list pgsql-patches

From Robert Lor
Subject Re: DTrace probe patch for OS X Leopard
Date
Msg-id 47C83CB2.7040306@sun.com
Whole thread Raw
In response to Re: DTrace probe patch for OS X Leopard  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DTrace probe patch for OS X Leopard
Re: DTrace probe patch for OS X Leopard
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: DTrace probe patch for OS X Leopard
Next
From: Tom Lane
Date:
Subject: Re: DTrace probe patch for OS X Leopard