> Agreed here. You may add GRANT CREATE / ATTACH / BACKUP privileges
> here.

I do not agree here. BACKUP is not yet a priviledge and I do not think
that it belongs to it.

> In short words, I'm with you and Vlad. Server-wide SQL is handy for
> some tasks. But it requires site login and connection context. I.e.
> it doesn't make sense to use the current API which is
> database-bound. Perhaps a new isc_service_execute_sql() call would
> do the trick - it would use the already established (via
> isc_service_attach) services connection and parse the given SQL to
> create the appropriate SPB buffers and execute the necessary service
> internally. Just a nice SQL wrapper for the services API. Comments?

SQL - Structured Query Language. What in common has SQL with the
backup process? Or SQL is Service Query Language?

I suggest first to agree whether we need scripting (in whatever
language) on the server side. What are the tasks that one want to
solve with the server-side scripting, why it is better to put this
into the server and only after this think about the scripting language.

If we start extending SQL to support system tasks, we will end up in
creating client tools that need to parse the text output of the
command. Can one integrate database statistics into their application
without parsing the server output? Is it possible to write nice GUI
that does exactly this task? Can one receive information about the
backup/restore progress without parsing the output of the server? Is
it possible to have a localized output for it?

Sorry, but I believe that this is not correct approach. So far I see
that only CREATE/DROP USER extension is integrated into the database,
but already Nickolay's backup does not really fit there.

So, we should either go Borland way, export all sensible data via
tables where one can use INSERT/UPDATE/DELETE statements (personally I
like this approach much more than any other) or we create a management
console for Firebird to support all such tasks. The scripting language
can be SQL-like, but we should not use that name in order to avoid
misunderstanding.

Roman