Frank,

Sorry to be late with the answer, but I'm slightly swamped.

>The same is true if gpre is called with the -e (ignore case) switch,
>but this will cause other problems.

Dare I ask what?

>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.

Somewhere in there, there ought to be a test of symbol and an
error path. The reason why there isn't is that this code runs
after the request has been parsed, so all aliases should be in
the hash table. That's not a reason not to have a test and
error message, just an explanation why this didn't show up
before.

Historically, both the embedded language and the qualifiers
were case sensitive unless the -e switch was used. I suspect
that the actual error is somewhere in PAR or SQL, which is upcasing
aliases and causing the wrong tok_string to be sent to this
routine. It's probably near whatever it is that handles
delimited identifiers.

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

IMHO, breaking existing programs by making things more aesthetic
leads to a certain lack of popularity among the users of those
existing programs.

Regards,

Ann