Martijn Tonies wrote:

>>>Actually, I disagree. IMO, it should raise an error so that it shows
>>>the user that there is a field "F2" in the table. That way, "undefined"
>>>behaviour can be avoided.
>>
>>Martijn, if I thought everyone would agree, I wouldn't have raised it
>>for discussion.
>
>>Maybe would should play a game. We'll call anyone who favors
>>"undefined" type A; anyone who favors a rule type B, and anyone who
>>favors an error, type C. I've come out of a type A. You're clearly a
>>type C. Can we guess were everyone else will fall?
>>
>>Helen, I'd guess B. Paul, loosy-goosy, definitely an A. Dmitri likes
>>order, so I'll guess B. Like always, I haven't the slightest idea of
>>where Nickolay might land, but we can probably rule out A.
>>
>>Other guesses?
>
> Well, the reason I'm type "C" is that I look at it from a user
> point of view. I remember someone saying "give a user enough
> rope and they will hang themselves". In this particular case, I'd
> like to avoid users entangling themselves.
>
> Remember the ambiguity issue? Those results were "undefined"
> and it was fixed.

From a compatibility point of view, and unqualified alias should match
the unqualified definition of it. Just been stung by something similar
coming from a MySQL/Posgres port. If there is not a matching alias, then
the ambiguity rule comes in.
( and the proposed fix failed that test as well ;) )

But when the problem is explained to MySQL/Posgres users ( the TikiPro
group ) THEY see the need to remove potential ambiguity and we correct
the ALIAS names to be 'unique'.

So I'd opt for an ambiguity error - and then correct the cross engine
SQL in the ports that hit it.

The ONE thing that I DO need is the ability to ORDER BY an ALIAS, as
much of the PHP order selection code inserts a field name which is not
easy to convert to a column number when there are multiple routes to
building the query, with varying select lists :(

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services