MonetDB

fix and test have been propagated to the development trunk
and testing confirmed the fix.
closing.

added test in May2009 release branch
(sql/src/test/BugTracker-2009/Tests/select_X_where_bla_EQ_whatever.SF-2825974.sql

The report can be closed, once the test has been propagated to the
development trunk,
and the code fix has been propagated to the development trunk, or the
alternative fix on the development trunk has been verified (see comments
below),
and nightly testing has confirmed the fix(es) for both the May2009 release
branch (or its successor Aug2009) and the development trunk.

For the records:

===================================================================
2009/07/31 - nielsnes: sql/src/server/rel_select.mx,1.143.2.5
fix crash with select * from 'whatever' = bla
===================================================================
2009/07/31 - stmane: sql/src/server/rel_select.mx,1.143.2.6

"selection" might be NULL in this case;
hence, we postpone dereferencing it
until we are sure it is not NULL.

NOTE:
this and Niels' previous checkin might (will)
conflict with
"
2009/07/25 - nielsnes: sql/src/server/rel_select.mx,1.148
added support for 'create cluster name on tname ( column list )'
which caused lots of changes all over the place.

also fixed (moved code out of sql -> mkey)
moved finally copy into over to a function and into relational alg.
"
during propagation;

in fact, the above mentioned checkin on the development trunk
might (does?) subsume these two checkin on the May2009 branch
(needs to be verified!)
===================================================================

I see that the provided patch should not check for selection->h but
selection like Niels did. Both work probably because ->h is the first
element of the struct.

Correction:

1)
On the May2009 release branch, the provided patch results in

sql>select * where bla = "whatever";
!SELECT: identifier 'bla' unknown
0 tuples

ps:

1)
On the May2009 release branch, the provided patch results in

sql>select * where bla = "whatever";
!SELECT: a query should atleast have a selection and/or a from part
0 tuples


2)
On the May2009 release branch, the provided patch does not appear to
"harm" any of the tests in the sql repository,
i.e., after applying the patch, `Mtest.py -r` reports the same as it did
before.

Just for the records:

In the development trunk, the following checkin appears to avoid the
crash:
===================================================================
2009/07/25 - nielsnes: sql/src/server/rel_select.mx,1.148
added support for 'create cluster name on tname ( column list )'
which caused lots of changes all over the place.

also fixed (moved code out of sql -> mkey)
moved finally copy into over to a function and into relational alg.
===================================================================

(cf. `cvs diff -r1.14{7,8} sql/src/server/rel_select.mx` for details)

sql>select * where bla = "whatever";
!SELECT: a query should atleast have a selection and/or a from part
0 tuples

(While this problem has been reported for the development trunk (CVS HEAD)
and the provided patch represents a diff with the development trunk
(revision 1.147 of sql/src/server/rel_select.mx, i.e., before the above
patch), the problem seems occur also in the May2009 release branch, and the
patch appears to be applicable there, too.)

I meant origin as "what was wrong in the code".

selection->h is not available with broken queries, must be explicitly
checked before use. Removes void cast of where because the variable is in
use.

The origin of the problem was a user entering a malformed query on my
webinterface that segfaulted monet. The patch implements a null check to
prevent n->* to be used.

Would it be possible to provide a context diff to ensure correct automatic
application (or prevent incorrect application automatic application) even
in case the original code base has changed in the meantime?

Would it be possible to provide the context diff in unified format to
improve human readability?
(admittedly personal taste)

Would it be possible to explain/document the details of the patch, and
hence enlighten us what the origin of the actual problem was, and how it
has been solved?

Thank you very much in advance!

The attached file basically prevents the crash, but I wonder if we can
solve it higher in the tree. Output now is:

sql>select * where bla = "whatever";
!SELECT: identifier 'bla' unknown
0 tuples

So that looks good :)