tree 2005aedaa2465f69329882f1c41add4447b3d06f
parent 25660e50d7fec058993e65bad46481392789ec79
author John Gemignani <jrgemignani@gmail.com> 1698186301 -0700
committer GitHub <noreply@github.com> 1698186301 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJlOEQ9CRBK7hj4Ov3rIwAA4oMIAA61b8w3sjgVXVCCn914dXt9
 PTdqVR5vwxOvg/862wbEUJBsnYzvUTY1DgoLCbU4Yi0uDWMdzxpTgf+hQAo1lHe5
 fSVmlGMwoPeaSXpfHEPI7QiPy2KXL4yeSJ9am55ex+tC8c9IWcfxtWCjIWtXcr4q
 39676xNtpql1R7dnOsjuU52ZSyUbXlMBiphpw3DZffu9DdGSaltwrevSxwxdIfhJ
 5nYZb16OKRNwJPzxKIF6ZvOZnibvfiYEPCSjTOq+wxvJBc5jdYG56bbCxpErSrrS
 Szm13JzoexSaryjWbXLeke+EpL+IuaVK+UfkmtuAe5rPZZt/+vdHijfDjfZqylw=
 =r10Q
 -----END PGP SIGNATURE-----
 

Fix Issue 945 - incorrect count(*) return values (#1288)

Fixed issue 945 where count(*) would have incorrect return values.

NOTE -

We need to re-evaluate if we want to use output_node or not.
If output_node is set to false, then it basically short circuits
match for instances where a variable isn't specified -

    MATCH () RETURN 0;
    MATCH () MATCH () RETURN 0;

While, on the surface, this appears to be a good way to improve
execution time of commands that won't do anything, it also
causes chained commands to not work correctly. This is because
a match without a variable will still feed its tuples to the next
stage(s) even though they won't necessarily be sent to the output.
For example, with count(*) -

    MATCH () RETURN count(*);
    MATCH () MATCH RETURN count(*);

With output_node set to false, it won't send the tuples. We will
likely need to remove all of the output_node logic. However, this
needs to be reviewed. For now, we just set it to true and update
the output of the regression tests.

Updated regression tests to accomodate the change.
Added new regression tests to cover overlooked cases.