On Nov 25, 2013, at 11:21 PM, H.Merijn Brand <h.m.br...@xs4all.nl> wrote:
> As I always use 2. when writing scripts, mostly because I use quite a > few useful attributes in the 4th argument already, it is the most > logical place: easy to maintain, easy to read and easy to extend. Also very much specific to the DBI and DBDs, and a useful place for you as the developer to define how the DBI should interface with the database. > One of the huge disadvantages of putting everything in the DSN is the > you have to rethink if and when character like :, ;, ", and ' should be > escaped and how and that values like undef are pretty darn impossible > (unless the driver has taken the trouble to support that). And as far as I can tell, the DBI does not currently support any escaping at all in the DSN. I created a database with a comma in its name, and was unable to figure out how to get the DBI to connect to it. > The first method however has a big advantage when the script (or a > one-liner) is completely driven by environment settings. > > my $dbh = DBI->connect ($ENV{DBI_DSN}); > > which happens to be the (underdocumented) default for connect and thus > equivalent to > > my $dbh = DBI->connect; I dislike this, personally. As a developer, I *always* exercise a certain amount of control over what gets passed in the attribute hash. It would be a rare condition where I would want to let an end-user do it. A multi-database command-line tool like dbish would be one of those rare exceptions. Best, David