Nando Dessena wrote:

>Jim,
>
>J> I think that the domain of the SQL language should be the database, no
>J> more, no less. Things that aren't visible in the database shouldn't be
>J> manipulated through SQL.
>What about multi-database SQL queries? What about "create user" when
>using the scheme based on a central user database (as opposed to
>a user table embedded in the current database)? BTW, you *can* create
>an external file through a create table statement.
>
>
>

The way to handle multi-database queries is through a "mega-database
manager", a pseduo database containing the metadata and security
mappings between a single virtual and multiple physical databases. The
mega-database manager would be implemented as a provider and fits into
the overall architecture quite nicely.

"Create user" and user authentication is handled through a Vulcan
security plugin. What they do with it is dependent on the plugin's
internal design. The plugin is can do anything it has rights to do
inside or outside the database, but this is transparent to the user.

Yes, I know that somebody added "create table" for external tables, and
I would like to see the mechanism extended to require a site password
for security.

The ability to create files quite properly belongs to the system
manager, not a database user. If he wishes to delegate this right by
revealing the site password, that is his choice. But just like one use
can't destroy another user's table by creating another with the same
name, an untrusted user shouldn't be allowed to destroy another user's
external table by replacing it.