Re: Create function prototype as part of PG_FUNCTION_INFO_V1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Create function prototype as part of PG_FUNCTION_INFO_V1
Date: 2014-01-15 05:41:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> This idea has appeared at least twice now, in
> and . Even if it doesn't help with Windows issues, as discussed in the second thread, it still seems like a win for reducing boilerplate and accidental compiler warnings. So here is a patch for consideration.

Meh. I don't think that extension authors are really going to appreciate
changing from "thou shalt declare all thy functions" to "thou shalt
declare none of them". If the code were such that it wouldn't matter
whether a manual declaration were provided too, then that wouldn't be a
big deal --- but you seem to be ignoring the discussion in the one thread
cited above about PGDLLEXPORT.

Also, surely it is 100% bogus for fmgr.h to be declaring functions not
actually provided by fmgr.c. That will create about as many failure
modes as it removes, not to mention being conceptually wrong.

The latter point might possibly be worked around by putting the externs
for _PG_init and _PG_fini into the PG_MODULE_MAGIC macro, though I'm not
sure how well that works for multi-source-file extensions; the init
functions might be in some other file than the PG_MODULE_MAGIC call.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Chinner 2014-01-15 05:50:12 Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Previous Message Michael Paquier 2014-01-15 05:31:42 Re: CREATE TABLESPACE WITH