Re: add modulo (%) operator to pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add modulo (%) operator to pgbench
Date: 2015-01-05 15:47:21
Message-ID: alpine.DEB.2.10.1501051638170.23383@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G Johnston 2015-01-05 15:59:52 Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Previous Message Manuel Kniep 2015-01-05 15:39:43 segmentation fault in execTuples.c#ExecStoreVirtualTuple