Обсуждение: How to control the content of BKI files during installation process?

Is there any way to control (enable/disable) some parts of BKI file?
(actually, I mean not BKI files themselves but their prototypes -
include/catalog/pg_*.h)

For example, I add some function to include/catalog/pg_proc.h and want
to have ability to enable/disable it during installation process
(e.g., with some configure's options such as --enable-my-proc). The
thing is that genbki.sh doesn't understand preprocessor instructions -
so, I cannot use #ifdef.

Maybe somebody has already encountered with this problem and invented
some workaround?

-- 
Best regards,
Nikolay

On Mon, Aug 14, 2006 at 12:31:30PM +0400, Nikolay Samokhvalov wrote:
> Is there any way to control (enable/disable) some parts of BKI file?
> (actually, I mean not BKI files themselves but their prototypes -
> include/catalog/pg_*.h)

No, because that's a bad idea. Even time somethin gthe catalog changes,
you have to bump the CATVERSION and reinitialize the cluster. By making
that happen by changing an ifdef is a recipie for disaster.

> For example, I add some function to include/catalog/pg_proc.h and want
> to have ability to enable/disable it during installation process
> (e.g., with some configure's options such as --enable-my-proc). The
> thing is that genbki.sh doesn't understand preprocessor instructions -
> so, I cannot use #ifdef.

Sounds like you really want your function to be an external module. In
that case you can simply ship an SQL file that creates the functions on
demand... Or perhaps at the end of the initdb?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Mon, Aug 14, 2006 at 12:31:30PM +0400, Nikolay Samokhvalov wrote:
>> Is there any way to control (enable/disable) some parts of BKI file?

> Sounds like you really want your function to be an external module. In
> that case you can simply ship an SQL file that creates the functions on
> demand... Or perhaps at the end of the initdb?

My thought exactly.  Model it after a contrib module, not a built-in
function.
        regards, tom lane