Subject | Re: [Firebird-Architect] Re: the insert into t select * from t infinite loop |
---|---|
Author | Alexandre Benson Smith |
Post date | 2005-07-05T16:12:32Z |
Ann W. Harrison wrote:
Taking a ride in this discussion:
One thing that most newcomers to FB strikes is
select
*
from
A
where
AI.B_ID in (select B.B_ID from B where B.B = 'X')
This query are treated as correlated, but in fact aren't, there is some
possibility to solve the both problems (infinite loop and this) at once ?
The only way to do it is to materialize the sub-query records ? (what
leads to the problem of big result set kept in memory)
The query could be rewriten as:
select
A.*
from
A
join B on (B.B_ID = A.B_ID)
where
B.B = 'X'
But I think the former is easier to read and is the first attempt made
by who como from other DB Engine.
I think the Arno's suggestion will address this case too.
Sorry for going off the main topic.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
>Dmitry Yemanov wrote:Hi !
>
>
>>And this is what the SQL spec explicitly requires:
>>
>>13) Let QT be the table specified by the <query expression>
>>...
>>5) QT is effectively evaluated before insertion of any rows into T.
>>
>>
>
>The keyword in that statement is "effectively". If we can get the
>effect, without the overhead, using an existing mechanism, maybe we can
>solve the problem.
>
>
>Regards,
>
>
>Ann
>
>
>
Taking a ride in this discussion:
One thing that most newcomers to FB strikes is
select
*
from
A
where
AI.B_ID in (select B.B_ID from B where B.B = 'X')
This query are treated as correlated, but in fact aren't, there is some
possibility to solve the both problems (infinite loop and this) at once ?
The only way to do it is to materialize the sub-query records ? (what
leads to the problem of big result set kept in memory)
The query could be rewriten as:
select
A.*
from
A
join B on (B.B_ID = A.B_ID)
where
B.B = 'X'
But I think the former is easier to read and is the first attempt made
by who como from other DB Engine.
I think the Arno's suggestion will address this case too.
Sorry for going off the main topic.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br