> >> If former - we don't need PROVIDER clause then - it should be part of
> >> Firebird. BTW, we don't have clause to register provider :)
> >
> > Because we don't need it. If provider will be regular Vulcan-style provider
> > it will be registered in appropriate config file
>
> Do you want to implement ODBC, JDBC or other adapters as providers in
> Vulcan architecture?

Why not ? Adapter must implement some subset of usual ISC API

> >>> 2. Login mappings management
> >> User name/password is not enough, we have to support certificates at
> >> least. I think we should split security part into another thread.
> >
> > While i agree that we may discuss security separate i not agree we _must_
> > support anything except password. If we will support certificates - good. But, please,
> > not require it
>
> No, I do not require it, I just say that we have to consider the PAM
> architecture Alex wanted to implement. The mechanism should be easy to
> extend with other exotic things like single-signon, etc.

When PAM will be implemented it will change syntax of usual CREATE USER statement
(if we'll have it ;). This changes will be picked up by CREATE REMOTE USER too

> >> That means that external tables has to be defined in the database
> >> explicitly. As to the explicit queries - if they are used often - people
> >> can define them as views (finally - as selectable procedures, add syntax
> >> extension to CREATE PROCEDURE statement).
> >
> > This way is used by ASA. I very very not like it. It is hard in use and require many
> > efforts from end-user.
>
> Can you provide a list of problems with this solution? Why is it hard to
> use and what exactly efforts are required from end-user (not database
> developer/administrator)?

You force user to "register" each and every foreign table to make user able to query it.
Even if i need to query it once and forget i need to register table, query it and unregister.

Next. You can't force external data sourse to not change its objects definitions. In your
schema we must make according changes in our definition. It may be very hard because
of stored dependencies. In my case all we need is to recompile statement failed at run-time
and correct it if needed

> Who is end-user in our case? Software developer or user of the software?

User of software called "Firebird" ;)

> >> If we extend the CREATE TABLE declaration as shown above, this problem
> >> disappears - it will use local identifiers.
> >
> > This is the only positive i see in extending CREATE TABLE :)
>
> Well... if you have a better idea to handle long tables names from other
> database engines in XSQLVAR without changing the XSQLDA version or API -
> I'm all ears :)

Change real table name by some alias is a bad idea, i think. It force you to write
query and keep in mind both names. Imagine you need to query 3 such tables at once,
5 tables ?

Regards,
Vlad