pgbench's expression parsing & negative numbers

Поиск
Список
Период
Сортировка
От Andres Freund
Тема pgbench's expression parsing & negative numbers
Дата
Msg-id 20171212052943.k2hlckfkeft3eiio@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: pgbench's expression parsing & negative numbers  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: pgbench's expression parsing & negative numbers  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: pg_dumpall -r -c try to drop user postgres
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] A design for amcheck heapam verification