Hi,

> Could we find a fix for that problem by identifying statements that
> might be susceptible - including obscurities like:
>
> insert into t select * from a
> where a.t_val in (select t_val from t)
>
> and checking somewhere that the input values aren't dependent on a
> record that's listed in the verb undo log?

This doesn't fix this problem:

SELECT
*
FROM
TableX x
WHERE
x.ID IN (SELECT FIRST 5 y.ID FROM TableY)

Which is the same problem IMO.

Uncorrelated IN predicate with sub-query should build a "temp-list" from the results of the
sub-query. With using EXISTS you will always force back the "old" behaviour and that's exactly what
i would like to see.

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Interbase and Firebird users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info