Re: Poorly-thought-out handling of double variables in pgbench - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Poorly-thought-out handling of double variables in pgbench
Date
Msg-id 16451.1462547620@sss.pgh.pa.us
Whole thread Raw
In response to Re: Poorly-thought-out handling of double variables in pgbench  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Poorly-thought-out handling of double variables in pgbench  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> This is a definite improvement.

> I like the lazyness between string & numeric forms, and for sorting, that 
> is what was needed doing to have something clean.

> Applied on head, it works for me.

OK, pushed.

> While testing the patch I found a minor preexisting (mine...) bug: when 
> string-scanning doubles, whether the whole string is consumed or not is 
> not checked. This means that -D x=0one is interpreted as double 0.

> I came up with the attached check, but maybe there is a cleaner way to do 
> that.

I like the way the zic code does it:
     else /* type should be double */     {         double dv; 
!         if (sscanf(var->value, "%lf", &dv) != 1)         {             fprintf(stderr,                     "malformed
variable\"%s\" value: \"%s\"\n",
 
--- 928,936 ----     else /* type should be double */     {         double dv;
+         char xs; 
!         if (sscanf(var->value, "%lf%c", &dv, &xs) != 1)         {             fprintf(stderr,
"malformedvariable \"%s\" value: \"%s\"\n",
 

This relies on the idea that if there is any trailing junk, one character
will get assigned into "xs" and then sscanf will say it filled two fields.
Otherwise, it'll report filling only one field (or none, if there's
no number either).  This requires only a minimal amount of code and no
extra strlen() calculations.

Neither way allows for trailing whitespace, though.  I don't see that
that's important here.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Perf Benchmarking and regression.
Next
From: Vladimir Gordiychuk
Date:
Subject: Stopping logical replication protocol