Hi,

I'm hunting a bug in gpre that causes a core dump under
certain circumstances.

The following code snippet will cause gpre to segfault,
if sql dialect 3 is used.

EXEC SQL DECLARE sc CURSOR FOR
SELECT r.rdb$field_name,
f.rdb$field_type,
f.rdb$field_length,
f.rdb$field_precision,
f.rdb$field_scale,
r.rdb$field_position
FROM rdb$relation_fields r, rdb$types t, rdb$fields f
WHERE r.rdb$relation_name= UPPER( :t_name ) AND
f.rdb$field_name=r.rdb$field_source AND
t.rdb$field_name='RDB$FIELD_TYPE';

If the qualifiers are changed to uppercase it will pass
gpre without problems.
The same is true if gpre is called with the -e (ignore case) switch,
but this will cause other problems.

The culprit is the following code from resolve in gpre/sqe.c:

/* Now search alternatives for the qualifier */

symbol = HSH_lookup (q_token->tok_string);
if ( (symbol == NULL) && (sw_case || sw_sql_dialect ==
SQL_DIALECT_V5))
symbol = HSH_lookup2 (q_token->tok_string);

Here we end up with symbol==null because we don't allow HSH_lookup2
(which is case insensitive) for sql dialect 2 and 3.


Some lines below we do
if (symbol->sym_type == SYM_relation)

and bingo: segfault.

IMHO, as the user didn't quote the identifiers, they should be
considered case insensitive regardless of sql dialect.

If we say that the above ESQL isn't valid for sql dialect 2 or 3
we should throw an error instead of dumping core.

So, what shall I do?

Frank

--
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
their tears have healing powers and they make highly faithful pets."
- J.K. Rowling
http://sourceforge.net/projects/firebird