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 a/src/bin/pgbenc
Teodor Sigaev writes:
> Thank you, pushed
Some of the Windows buildfarm members aren't too happy with this.
regards, tom lane
Thank you, pushed
Thanks!
--
Fabien.
Thank you, pushed
Fabien COELHO wrote:
SQL doesn't evaluate unneeded arguments:
Here is a version with some lazy evaluation for and, or & case.
v23 is a rebase.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
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
+++ b/doc/src/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 a/doc/src/sg
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 co
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
Hello Teodor,
replaced -1 by 0x so that the code is hopefully clearer.
I changed 0xff constant to ~INT64CONST(0), seems, it's more consistent way.
Also I remove some whitespaces in exprparse.y. Fixed version in attachment.
Fine, quite readable this way.
Actually, I prefer to see s
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. Than
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. Curre
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
>>> pg_strncasecmp("tru", "true", 1) will
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 == str
Hello Teodor,
Huh, you are fast. Rebase patch during half an hour.
Hmmm... just lucky, and other after lunch tasks were more demanding.
I haven't objection about patch idea, but I see some gotchas in coding.
1) /* Try to convert variable to numeric form; return false on failure */
static b
Huh, you are fast. Rebase patch during half an hour.
I haven't objection about patch idea, but I see some gotchas in coding.
1) /* Try to convert variable to numeric form; return false on failure */
static bool
makeVariableValue(Variable *var)
as now, makeVariableValue() convert value of eny ty
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 4431fc3..ea8f
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 C
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 b/doc/src/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 after the documentation xml-ization.
>
> all test
20 matches
Mail list logo
