Mark,
> On 12-7-2012 22:14, Leyne, Sean wrote:
> > Bad example, I should have said that:
> >
> > SELECT ... FROM ... WHERE ColumnA = COS( ColumnB)
> >
> > Doesn't use an index when it should be able to, just as the engine is
> > able to use an index for this query
> >
> > SELECT ... FROM
13.07.2012 0:14, Leyne, Sean wrote:
>
> Bad example, I should have said that:
>
> SELECT ... FROM ... WHERE ColumnA = COS( ColumnB)
>
> Doesn't use an index when it should be able to, just as the engine is able to
> use an index for this query
>
> SELECT ... FROM ... WHERE ColumnA = Co
On 12-7-2012 22:14, Leyne, Sean wrote:
> Bad example, I should have said that:
>
> SELECT ... FROM ... WHERE ColumnA = COS( ColumnB)
>
> Doesn't use an index when it should be able to, just as the engine is able to
> use an index for this query
>
> SELECT ... FROM ... WHERE ColumnA =
Dmitry,
> > First, in the original example:
> > select u, u, u
> > from (select gen_uuid() u from rdb$database)
> >
> > there is only one instance of the expression -- there are 3 references to
> > the
> *resolved* expression.
>
> In Firebird, there is no such thing as "instance of the e
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" simi
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.
2) Create art
12.07.2012 22:08, Leyne, Sean wrote:
>
> This seems to be wrong.
I don't say it's correct, I just explain why it works this way.
> First, in the original example:
> select u, u, u
> from (select gen_uuid() u from rdb$database)
>
> there is only one instance of the expression -- there
On 12/07/2012 13:29, Dmitry Yemanov wrote:
> 12.07.2012 19:44, Paul Vinkenoog wrote:
>> So... have we implemented the DT and CTE features correctly?
> I believe it has nothing to do with our implementation of DTs and CTEs.
> Create a view with gen_id and and select that field thrice - you will
>
Dmitry,
> 12.07.2012 19:44, Paul Vinkenoog wrote:
> >
> > So... have we implemented the DT and CTE features correctly?
>
> I believe it has nothing to do with our implementation of DTs and CTEs.
> Create a view with gen_id and and select that field thrice - you will get the
> same result. And vie
12.07.2012 19:44, Paul Vinkenoog wrote:
>
> So... have we implemented the DT and CTE features correctly?
I believe it has nothing to do with our implementation of DTs and CTEs.
Create a view with gen_id and and select that field thrice - you will
get the same result. And views are here for a few
Hi all,
If I do this:
select u, u, u
from (select gen_uuid() u from rdb$database)
...I get three different UUID's.
I would have expected the derived table to be evaluated once. The subquery
returns a single row with one column. Selecting this column three times should
get me three times t
11 matches
Mail list logo
