Subject | Re: [Firebird-Architect] XSQLDA/XSQLVAR issues |
---|---|
Author | Jim Starkey |
Post date | 2005-01-09T12:45:45Z |
Arno Brinkman wrote:
select
schema,
tablename,
tableid as id
from
system.tables
where
id=46
in Netfrastructure dutifully gives
SCHEMA TABLENAME ID
---------- ---------- --
NETFRASITE MEMBERSHIP 46
Last I heard, neither Oracle nor Microsoft were heavy Firebird users, so
I had think their opinions should carry much weight.
The important questions are:
1. Is it useful?
2. Is it well defined?
3. Does it violate the standard?
4. Is it likely to violate the standard at some future if the SQL
committee does something borderline plausible but dumb?
A general implement is very easy. Hang a pointer to a select object off
the SQL context object. If a single name identifier doesn't resolve to
a context column name, check it against the select list. The immediate
complication is that the current guy who resolves an identifier to a
context returns only a field pointer, not a compiled expression which is
necessary to support aliases expressions.
We really should encrypt pass1.cpp so only the most experienced,
hardened, least impressionable programmers are exposed to such hideous,
deplorable, disease infested, festering code. It is exactly the sort of
code that makes me want to to make a special programmers' editor that
supports block move but not cut and paste. Ugh.
[Non-text portions of this message have been removed]
>If i run this in MSSQL :Running the following:
>
>SELECT
> ID,
> RELATIEID AS ALIAS
>FROM
> Orders
>WHERE
> ALIAS = 3668
>
>it fails with:
>Invalid column name 'ALIAS'.
>
>AFAIK it only support aliasses in the ORDER BY clause and NOT in the WHERE,
>GROUP BY, HAVING clauses.
>
>Running this on Oracle gives also a error:
>ORA-00904: "ALIAS": invalid identifier
>
>
>
select
schema,
tablename,
tableid as id
from
system.tables
where
id=46
in Netfrastructure dutifully gives
SCHEMA TABLENAME ID
---------- ---------- --
NETFRASITE MEMBERSHIP 46
Last I heard, neither Oracle nor Microsoft were heavy Firebird users, so
I had think their opinions should carry much weight.
The important questions are:
1. Is it useful?
2. Is it well defined?
3. Does it violate the standard?
4. Is it likely to violate the standard at some future if the SQL
committee does something borderline plausible but dumb?
A general implement is very easy. Hang a pointer to a select object off
the SQL context object. If a single name identifier doesn't resolve to
a context column name, check it against the select list. The immediate
complication is that the current guy who resolves an identifier to a
context returns only a field pointer, not a compiled expression which is
necessary to support aliases expressions.
We really should encrypt pass1.cpp so only the most experienced,
hardened, least impressionable programmers are exposed to such hideous,
deplorable, disease infested, festering code. It is exactly the sort of
code that makes me want to to make a special programmers' editor that
supports block move but not cut and paste. Ugh.
[Non-text portions of this message have been removed]