Hi Dmitry,

> Obviously, this is practically useless due to the possible
> ambiguity. So libraries do:

> SELECT T1.COL, T2.COL
> FROM TAB1 T1, TAB2 T2
> WHERE TAB1.COL = 0

> Which worked quite well. But we have two problems here:

> 1) it doesn't work with two references to a single relation
> (unexpected result is produced)
> 2) this query is no longer valid in FB 2.0 (SQL-99 rejects
> it as well)

> Shortly said, FB 2.0 breaks a significant subset of the
> FIBPlus features. IBO is also expected to be affected.
> Cannot say for others.

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

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.

It strikes me that, supporting column aliases in all the
SQL clauses, would give all libraries a simpler way to
manage dynamic construction of unambiguous references.

That is; Given that the old TAB1.COL method is no longer
going to work the libraries are going to need to change.
The change could be to use relation aliases (if they become
available) or the change could be to support column aliases
instead. If column aliases work then the existing XSQLVAR
would be adequate.

> 1) Extend both isc_dsql_sql_info() and XSQLDA (introducing
> a new version) every time. This is what Borland does now.
> 2) Freeze XSQLDA structure (for compatibility reasons) and
> extend only isc_dsql_sql_info(). It doesn't allow us to use
> longer metadata names or namespaces, but may satisfy the
> current needs.
> 3) Introduce new API which uses a new structure (or just
> simplified XSQLDA) for input/output data only and returns
> all relevant describe information via isc_dsql_sql_info().

> Opinions?

If column aliases start to actually work in SQL then I would
suggest that the XSQLDA need not change (at least not yet).

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.

My opinion is...

Until FB is going to support unicode for all metadata then
try to retain the current XSQLDA as it is. When metadata
supports unicode then it may be time to introduce new API
methods (perhaps fb_XXXXX methods) that support unicode.
Retain the old api methods to retain support for libraries
to reference (at least) old databases via the new server.

Not sure if this all makes sense.

--
Geoff Worboys
Telesis Computing