Re: add modulo (%) operator to pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: add modulo (%) operator to pgbench
Date
Msg-id alpine.DEB.2.10.1501051638170.23383@sto
Whole thread Raw
In response to Re: add modulo (%) operator to pgbench  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
>> I'm also just looking at you ERROR() macro, it seems that core code is
>> quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is
>> not defined. I'd say this needs to be fixed too. Have a look at the trick
>> used in elog.h for when HAVE__VA_ARGS  is not defined.
>
> Hm, I just looked at the previous version which used ERROR rather than
> LOCATE and LOCATION, and I liked that approach better.  Can we get that
> back?

It seems that postgresql must be able to compile with a preprocessor which 
does not handle varargs macros, so I thought it simpler to just expand the 
macro. If we must have it without a vararg macro, it means creating an 
adhoc vararg function to handle the vfprintf and exit. Oviously it can be 
done, if vfprintf is available. The prior style was to repeat fprintf/exit 
everywhere, I wanted to improve a little, but not to bother too much about 
portability constraints with pre C99 compilers.

> I understand that for the purposes of this patch it's easier to
> not change existing fprintf()/exit() calls, though.

The issue is really the portability constraints. C99 is only 16 years old, 
so it is a minor language:-)

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Manuel Kniep
Date:
Subject: segmentation fault in execTuples.c#ExecStoreVirtualTuple
Next
From: David G Johnston
Date:
Subject: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs