Re: [COMMITTERS] pgsql: pgbench: Support double constants and functions.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <rhaas(at)postgresql(dot)org>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: pgbench: Support double constants and functions.
Date: 2016-03-29 04:25:47
Message-ID: CAB7nPqQsz0CLBVPzfKBvAuz+ixdFf-1RB2qx+vihq46coXmwvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas <rhaas(at)postgresql(dot)org> wrote:
> pgbench: Support double constants and functions.
>
> The new functions are pi(), random(), random_exponential(),
> random_gaussian(), and sqrt(). I was worried that this would be
> slower than before, but, if anything, it actually turns out to be
> slightly faster, because we now express the built-in pgbench scripts
> using fewer lines; each \setrandom can be merged into a subsequent
> \set.

Buildfarm is complaining about a couple of things here:
src/bin/pgbench/exprparse.c(139): error C2365: 'DOUBLE' :
redefinition; previous definition was 'typedef'
[C:\buildfarm\buildenv\HEAD\pgsql.build\pgbench.vcxproj]
src/bin/pgbench/pgbench.c(1046): error C2065: 'INT64_MIN' :
undeclared identifier
[C:\buildfarm\buildenv\HEAD\pgsql.build\pgbench.vcxproj]
src/bin/pgbench/exprparse.c(139): error C2086: 'yytokentype DOUBLE'
: redefinition [C:\buildfarm\buildenv\HEAD\pgsql.build\pgbench.vcxproj]
src/bin/pgbench/pgbench.c(1046): error C2065: 'INT64_MAX' :
undeclared identifier
[C:\buildfarm\buildenv\HEAD\pgsql.build\pgbench.vcxproj]
src/bin/pgbench/exprscan.l(131): error C2275: 'DOUBLE' : illegal use
of this type as an expression (src/bin/pgbench/exprparse.c)
[C:\buildfarm\buildenv\HEAD\pgsql.build\pgbench.vcxproj]

Instead of INT64_MIN and INT64_MAX, I think that it would be better to
use PG_INT64_MIN and PG_INT64_MAX. Note as well that DOUBLE is an
existing variable type in VS (while INTEGER is not), and it is true
that it is not directly documented:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221627%28v=vs.85%29.aspx
A way to fix compilation here is to rename those tokens to something
that will never conflict, like in the attached to DOUBLE_VAR and
INTEGER_VAR, both exprparse.y and exprparse.l need an update.
--
Michael

Attachment Content-Type Size
pgbench-fix-vs.patch binary/octet-stream 2.1 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Christian Ullrich 2016-03-29 04:36:04 Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.
Previous Message Tom Lane 2016-03-29 03:21:54 Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

Browse pgsql-hackers by date

  From Date Subject
Next Message Christian Ullrich 2016-03-29 04:36:04 Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.
Previous Message Thomas Munro 2016-03-29 04:11:29 Re: Proposal: "Causal reads" mode for load balancing reads without stale data