Re: Performance optimization of btree binary search

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Performance optimization of btree binary search
Дата
Msg-id 1386301050.2743.17.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: Performance optimization of btree binary search  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: UNNEST with multiple args, and TABLE with multiple funcs
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: RFC: programmable file format for postgresql.conf