No, though I slightly prefer command line arguments over separate 
configuration entries. 1st because most people probably don't care and 
use the same db user anyway, and 2nd because those that *do* care 
probably don't want to put some superuser's credentials in a plain 
text configuration file either.

Any objections to this?

if the above turns out to be true...
... then having a dedicated sql account for admin stuff should solve 
this request.

Once we're fully converted to migrations/Horde_Db the live user 
shouldn't need CREATE privileges anymore, since we won't be using 
sequence tables.

I can see adding command-line arguments to the migration script for 
using different credentials, or just adding another set of SQL configs 
for administrative/table management use. Could be useful for eventual 
table management UI, too.

This isn't possible through SQL, unless you happen to use MySQL. The 
admins will already get an error message if the migration fails. It's 
up to the database to provide a useful error message.

I meant that it wasn't an issue to me the fact that the migration 
script uses the sql user configured in horde.
I Agree, and if horde sql user should have all the privileges needed 
to run the migration script, then the migration script doesn't need a 
user/password parameters.

So, since lots of admin/user are going to update to the new version of 
Horde, and the fact that up to now, horde sql user never had the ALTER 
privilege, can the migration script check for all needed sql privilege 
before running ?

This should prevent users from asking on the horde lists (or file a 
bug) because the migration script doesn't run correctly. Right now the 
migration script assume that sql user has all required privileges.

If this is not a problem, I can close this request? We might consider 
adding user/password parameters to the migration script at a later 
point.

But actually the Horde SQL user *always* needed at least CREATE 
permissions to create sequence tables. I don't see a good reason to 
grant CREATE and DELETE permissions but not ALTER permissions.

Yes, the migration scripts are using the sql user configured in horde.
But I don't think this is a problem, unless you want a dedicated SQL 
user for the migration tool.

The create.* scripts are going away, once the migration are complete.

You didn't mention this, but I guess the real problem is that the 
migration scripts are run with the sql user configured in horde now?

using MySQL (but I guess this can apply to other DB)

the recent new migration scripts require the DB user to have the ALTER 
privilege.
Can someone update scripts/sql/create.mysql.sql and add ALTER privilege.

I'm guessing that anyone who will update from Horde 3 to Horde 4 will 
run into this issue.

Can the migration scripts check, before running, that the DB user has 
the required privileges ?