On Tue, Nov 30, 2004 at 10:32:12PM +0000, Tim Bunce wrote:
> On Tue, Nov 30, 2004 at 09:38:47PM +0000, Nicholas Clark wrote:
> > On Tue, Nov 30, 2004 at 08:53:51PM +0000, Tim Bunce wrote:
> > The one that I've hit - specifying port and host, Pg vs Mysql (and SQlite):
> >
> > if ($dbspec->{driver} eq 'DBI:Pg') {
> > # Aaargh. Why aren't these things standarised?
> > $dsn = "DBI:Pg:host=$dbspec->{domain}";
> > # Aargh. W.T.F. is this case sensitivity here? It fails to connect
> > unless
> > # the name is all lowercase (as is stored within the non-case preserving
> > # pg DB)
> > $dsn .= lc ";dbname=$dbspec->{db_name}" if length $dbspec->{db_name};
> > $dsn .= ";port=$dbspec->{port}" if defined $dbspec->{port};
> > } else {
> > $dsn .= ":port=$dbspec->{port}" if defined $dbspec->{port};
> > }
>
> It seems to me that the problem is of your own making.
> Why have separate hash elements for all these things in the first place?
Oops. 1 more line would have helped. This precedes my previous code:
my $dsn = "$dbspec->{driver}:$dbspec->{db_name}:$dbspec->{domain}";
Even if I keep the DSN in a flat string, I have to remember that MySQL
wants driver:DBname:hostname:port=# while Pg wants
driver:dbname:host=name;port=#
and to me needing to remember all this trivia seems wasteful.
It doesn't actually matter if its in a hash or flat string, there's too much
driver specific already even in the simple bits I would like flexibility in.
In general I find that a hash ref is useful as an argument to a function as
it provides named parameters, which avoids needing to remember a list order
for parameters, and also to have to fill in defaults to make the list up to
the position of the parameter you wish to change.
I guess I don't find it natural thinking about parameters as a single string.
Nicholas Clark
