> 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?

I dont know that its that simple. Some of us are real fence
sitters - I'd like a rule and an error, with room for undefined
behaviour in specific situations ;-)


The following is not a serious proposal. Just a suggestion of
how it would be done if SQL were a serious programming language
rather than just a mish-mash of (I dont even know what to call
it - perhaps English, thats a language I know with similar
problems :-). I am quite certain the 'S' in SQL does not
actually stand for "structured" - there are many other words
starting with 'S' that seem more appropriate.

Being a programmer I look at something like an SQL select
statement and see an entity with its own scope...

SELECT ...
FROM ...
etc

That is; The select statement defines a set of data, it is
not in and of itself a table or combination of tables, even
though that may be the source of the set. The statement is an
entirely new entity (similar to a C++ class - where the SELECT
is inheriting from one or more other classes (tables)).

So any names defined by the SELECT (column aliases, relation
aliases) become part of the local scope overriding anything
that may exist in external scopes. Names in the local scope
must be unique within the local scope - and may potentially
hide names that would come from external scopes.

So that something like:

SELECT
T.X AS Y,
T.Y AS X
FROM ATABLE T
WHERE Y = 4

Would work (the second field T.Y is not hidden by the first
alias because it has been qualified), the Y in the WHERE
clause actually refers to T.X because it was unqualified and
therefore uses the local scope's name.

Something like:

SELECT
T.X AS Y,
Y AS X
FROM ATABLE T
WHERE Y = 4

would result in T.X being returned in both fields.

SELECT
T.X AS A,
T.Y AS A
FROM ATABLE T
WHERE Y = 4

would result in an error, because we are trying to declare two
identical names ('A') in the local scope.

SQL compilers could produce warnings about name hiding - just
as our C++ compilers do for us with class declarations.

This leaves us with:

SELECT
[expression] AS X
FROM ATABLE T
WHERE X = 4

In one form of logic the [expression] could be treated as an
inline function so that the statement is seen internally as:

SELECT
[expression] AS X
FROM ATABLE T
WHERE [expression] = 4

However, to my logic, use of a column alias is like using a
reference to a value. So the statement would be seen
internally as:

SELECT
[expression] AS X
FROM ATABLE T
WHERE [value at field 1] = 4


Of course the idea that there is no specific order to the
fields in a select statement list makes name resolution...
interesting.

There are probably other things in there that I have missed,
but you get the idea. It would be nice to think that there
may be ideas in here worth borrowing to make aliases a truly
useful feature.

--
Geoff Worboys
Telesis Computing