On 12/07/2012 15:37, Dmitry Yemanov wrote: > 12.07.2012 22:20, Adriano dos Santos Fernandes wrote: > >> It's easy to change them both to run correct. > What do you mean? I can think of two solutions: > > 1) Track the duplicate references at the parser level and then embed > "hidden variables" similarly to how it was done for COALESCE.
Time showed "hidden variable" was a very bad idea. > 2) Create artificial context/stream for the every RSE and store > expression results from the select list there. > For every CTE/DT RSE... Kinda of a UnionSourceNode with a single stream. For views, it's not very obvious without analyze the (complex) code, but the DSQL code has no problem, as it already has a extra context and the query BLR access the fields from it. > The former one looks "bulky" to me, the latter one will degrade the raw > performance due to the extra memory copying. Am I missing anything? > > Sure it will degrade, and the minimal possible degradation will be the memory copy. But it will return correct results. A worst degradation is if the optimizer is not smart enough to optimize access to these fake-contexts for simple field lookups. Adriano ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
