Subject Re: [Firebird-Architect] XSQLDA/XSQLVAR issues
Author Dmitry Yemanov
"Geoff Worboys" <geoff@...> wrote:
>
> One thing I am curious about. If the handling of this has
> changed in FB 2.0 what about column aliases? Will FB 2.0
> finally accept column aliases in other clauses? eg:
>
> SELECT
> T1.COL AS T1COL,
> T2.COL
> FROM TAB1 T1, TAB2 T2
> WHERE T1COL = 0

Nope. I just don't know anyone seriously interested to implement this.
Personally, I wouldn't give it a high priority. BTW, is there anything else
than Sybase which supports such a feature? Oracle allows column aliases in
the ORDER BY clause only, and considering available ORDER BY <ordinal> this
doesn't look as a very nice improvement.

> I expect that the C++ library I have been working on will
> also be effected by the change you describe. However one
> of the things I have done in this library is make active
> use of the XSQLVAR aliasname field to store unique names
> for columns. This small insistence on the SQL (to insist
> that column alias names are given to avoid conflicts)
> makes all program column references much simpler to resolve.
> The only problem with this approach at the moment is that
> you cannot use column aliases when constructing SQL clauses,
> that is a right pain.

From the database user's POV I never felt the need in this feature. But
perhaps you the connectivity layer guys have your own requirements, so it's
at least worth discussing. But this is definitely not for v2.0.

> As for longer metadata names...
>
> There is more to it than just longer. It seems to me that
> the current problem is not the length of the metadata names
> but the fact that UNICODE is not supported. If unicode was
> going to work then the names would reduce to 10 chars and so
> the length becomes an issue.

I did't propose to introduce longer names now ;-) This is not going to
happen until the current UNICODE limitations are solved. Even more, I
seriously doubt a vital importance of this improvement at all. I'd better
have either a SQL-99 compliant schemas, or Jim's lovely multi-level
namespaces with old good 31-char identifiers. But this is just me. I hope us
to get back to this discussion for v3.0 or whatever.


Dmitry