pgbench's expression parsing & negative numbers

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pgbench's expression parsing & negative numbers
Date: 2017-12-12 05:29:43
Message-ID: 20171212052943.k2hlckfkeft3eiio@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

working on overflow correctness in pg I noticed that pgbench isn't quite
there. I assume it won't matter terribly often, but the way it parses
integers makes it incorrect for, at least, the negativemost number.

It directly parses the integer input using:
{digit}+ {
yylval->ival = strtoint64(yytext);
return INTEGER_CONST;
}

but that unfortunately means that the sign is no included in the call to
strtoint64. Which in turn means you can't correctly parse PG_INT64_MIN,
because that's not representable as a positive number on a two's
complement machine (i.e. everywhere). Preliminary testing shows that
that can relatively easily fixed by just prefixing [-+]? to the relevant
exprscan.l rules. But it might also not be a bad idea to simply defer
parsing of the number until exprparse.y has its hand on the number?

There's plenty other things wrong with overflow handling too, especially
evalFunc() basically just doesn't care. I'll come up with a patch for
that sometime soon.

A third complaint I have is that the tap tests are pretty hard to parse
for humans.

Greetings,

Andres Freund

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-12-12 05:35:24 Re: [HACKERS] A design for amcheck heapam verification
Previous Message Jeff Janes 2017-12-12 05:23:43 Re: pg_dumpall -r -c try to drop user postgres