Some of the Windows buildfarm members aren't too happy with this.
Indeed.
Windows prettyprinting of double inserts a spurious "0" at the beginning
of the exponent. Makes it look like an octal.
Here is a patch to fix it, which I cannot test on Windows.
--
Fabien.diff --git
Teodor Sigaev writes:
> Thank you, pushed
Some of the Windows buildfarm members aren't too happy with this.
regards, tom lane
SQL doesn't evaluate unneeded arguments:
Here is a version with some lazy evaluation for and, or & case.
v23 is a rebase.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 1519fe7..3dd492c 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++
Investigating your patch I found that all arguments of logical AND/OR and
CASE are always evaluated. Seems, it should not be for pair of reasons:
[...]
SQL doesn't evaluate unneeded arguments:
Here is a version with some lazy evaluation for and, or & case.
--
Fabien.diff --git
Here is a rebase after "pow" addition.
Huh, you are fast.
Investigating your patch I found that all arguments of logical AND/OR and CASE
are always evaluated. Seems, it should not be for pair of reasons:
- computing of unneeded args could be too expensive
- computing of unneeded args could
Hello Teodor,
So, I intend to push thish patch in current state. I saw several objections
from commiters in thread, but, seems, that objections are lifted. Am I right?
Here is a rebase after "pow" addition.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
I've checked, but truexxx is not accepted as true. I have added a test case
which fails on "malformed variable", i.e. it went up to scanning a double. When
comparing ("truexxx", "true", 7) the fifth char is different, so it is != 0. Or
I'm missing something.
Oh, my fault. I've missed that.
Hello Teodor,
It may be good for 't' of 'f' but it seems too free grammar to accept 'tr'
or 'fa' or even 'o' which actually not known to be on or off.
Yes, it really works like that. I tried to make something clearer than
"src/bin/psql/variable.c". Maybe I did not succeed.
Ok, I see.
2017-12-15 14:47 GMT+01:00 Teodor Sigaev :
> 2) In makeVariableValue():
>>> if (pg_strcasecmp(var->svalue, "null") == 0)
>>> ...
>>> else if (pg_strncasecmp(var->svalue, "true", slen)
>>>
>>> mixing of pg_strcasecmp and pg_strNcasecmp. And, IMHO, result of
>>>
2) In makeVariableValue():
if (pg_strcasecmp(var->svalue, "null") == 0)
...
else if (pg_strncasecmp(var->svalue, "true", slen)
mixing of pg_strcasecmp and pg_strNcasecmp. And, IMHO, result of
pg_strncasecmp("tru", "true", 1) will be 0.
Yep, but it cannot be called like that because slen ==
Attached v16 fixes those two errors. I regenerated the documentation with the
new xml toolchain, and made "check" overall and in pgbench.
Attached v17 is a rebase after the zipfian commit.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index
I'm not sure why it wasn't failing before, but I have issues building the
doc:
+are built into
pgbench
Missing '/' to close the xref
Indeed, missing xml-ization. The format was still SGML when the patch was
developed.
+ 1 3
Expecting ';' as the previous use ()
Indeed, a typo.
Hi,
> Regenerated v15 that applies cleanly on head. No changes.
I'm not sure why it wasn't failing before, but I have issues building the
doc:
+are built into
pgbench
Missing '/' to close the xref
+ 1 3
Expecting ';' as the previous use ()
On Fri, Dec 1, 2017 at 1:57 PM, Fabien
Here is a v13. No code changes, but TAP tests added to maintain pgbench
coverage to green.
Here is a v14, which is just a rebase after the documentation xml-ization.
Regenerated v15 that applies cleanly on head. No changes.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml
On Wed, Oct 25, 2017 at 5:57 PM, Pavel Stehule wrote:
> 2017-10-20 18:36 GMT+02:00 Fabien COELHO :
> Here is a v13. No code changes, but TAP tests added to maintain pgbench
> coverage to green.
>>
>>
>> Here is a v14, which is just a rebase
15 matches
Mail list logo