[feature request] Allow user/username in DSN

[H.Merijn Brand]

It is not documented, but DBD::mysql supports the user/pass in the DSN, which is very handy in dynamic DSN's and testing.
Would you consider allowing user/pass in DSN?

$dsn = "dbi:MariaDB:dbname=foo;user=tux;pass=secrit";
$dsn = "dbi:MariaDB:database=foo;username=tux;password=secrit";

[Jan Chochol]

I think, that this functionality was unintentionally removed in 78dce9d (different order of updates of$privateAttrHash), so it should not be problem to move it back.

[pali]

Hello @Tux! What is the purpose to abuse DBI API, which has standard defined way how to specify username and password, and add a new way to specify username and password? This would just confuse users what they should use, plus it is driver specific and incompatible with other DBI-compatible drivers. Also there is a question, if somebody specify both pass and password keys in DSN, then also password in correct/documented DBI->connect argument and also in connection hash parameters, which password should be used for connecting to database? And why? Seems like it just over-complicate things and usage... and I do not see much benefit in it to provide custom-driver behavior. Purpose of DBI is to have unified API for Perl application without need to care about used database driver.

[H.Merijn Brand]

1. My quest here was not the abuse, but the fact that MariaDB diverted from mysql, and I encountered a situation where this "feature" was actually used and did not work in DBD::MariaDB but did work in DBD::mysql. With my wish to move all scripts away from DBD::mysql in the direction of DBD::MariaDB (mostly because of Unicode), I'd like to see a real drop-in replacement.
2. Perl is full of "abuses". If someone/somebody invented something that is easy to use and supported, even if it is not documented (officially) in the API, I see no reason to disable such a feature just because it is not 100% documented API. If people use it, there is a use for it
3. Having just one parameter instead of three might be a lot easier. In the current API you would need to store three different items for a connection instead of just one. This sucks if your config is a key-value store, now you will get three entries per database connection, each prefixed with a data-connection tag. foo_test => "dbi:Pg:dbname=foo_test;user=tester", foo_accept => "dbi:Oracle:dbname=accept;user=dummy" would be a lot easier.

[pali]

Hm... Looks like this is something which could be implemented in DBI layer, not re-implemented in every one DBI driver. Could you open request directly in DBI project about it?

[pali]

Hello @Tux! I'm thinking about closing this issue as duplicate / forwarded to DBI issue perl5-dbi/dbi#87

[H.Merijn Brand]

It is much harder to do in DBI than in the DBD's, as the DBI has no knowledge of what DBD's support, but the DBD's have knowledge of what DBI supports.