Re: Performance optimization of btree binary search - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Performance optimization of btree binary search
Date
Msg-id 1386301050.2743.17.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: Performance optimization of btree binary search  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Thu, 2013-12-05 at 15:29 +0200, Heikki Linnakangas wrote:
> It happens to me about 75% of the time when I write a new C function. 
> These days, I usually realize it pretty quickly.
> 
> I wonder how easy it would be to make the compiler produce a warning 
> about it. Or issue a warning in PostgreSQL when you do CREATE
> FUNCTION 
> and the C function appears to be a V0 function.

Here is a related idea I've had:  Integrate the function declaration
into the PG_FUNCTION_INFO_V1 macro, like this:

#define PG_FUNCTION_INFO_V1(funcname) \
Datum funcname(PG_FUNCTION_ARGS); \
...

Because if you don't declare the function, you will get a compiler
warning for -Wmissing-prototypes.  Field experience shows that many
extension authors neglect to explicitly declare their entry-point
functions, presumably because they don't understand the cause of the
warning, or they don't look at the compiler output, so many extensions
unfortunately don't compile without warnings at the moment.

By putting the function declaration into the PG_FUNCTION_INFO_V1 macro,
everyone wins:

- fewer compiler warnings due to laziness
- no code bloat because of redundant function declarations
- accidental V0 functions are warned about
- prototypes of V1 function implementations are implicitly checked for
correctness





pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: UNNEST with multiple args, and TABLE with multiple funcs
Next
From: Peter Eisentraut
Date:
Subject: Re: RFC: programmable file format for postgresql.conf