On Mon 21 Jan 2002 08:01, Jonathan Leffler <[EMAIL PROTECTED]> wrote:
> >a) set ChopBlanks on by default (which they probably shouldn't)
> >
>
> Not guilty (referring to DBD::Informix, of course). Is ChopBlanks
> settable in the DBI->connect?
Yes:
sub DBDlogon (;$)
{
$dbh and return $dbh;
my %attr = (
RaiseError => 1,
PrintError => 1,
AutoCommit => 0,
ChopBlanks => 1,
ShowErrorStatement => 1,
);
if (@_ && ref $_[0]) {
my $r = shift;
foreach my $attr (keys %$r) { $attr{$attr} = $r->{$attr} }
}
if (exists $ENV{DBPATH} && -f "$ENV{DBPATH}/file.dbs") {
exists $attr{ScanLevel} or $attr{ScanLevel} = 7;
$dbh = DBI->connect ("DBI:Unify:", "", $ENV{USCHEMA}, \%attr) or
croak "connect: $!";
}
elsif (exists $ENV{ORACLE_HOME} && -d $ENV{ORACLE_HOME}) {
$attr{FetchHashKeyName} = "NAME_lc";
my ($dbu, $dbp) = split m:/: => $ENV{DBUSER};
$dbh = DBI->connect ("DBI:Oracle:", $dbu, $dbp, \%attr) or
croak "connect: $!";
}
else {
my $db = exists $ENV{MYSQLDB} ? $ENV{MYSQLDB} : "test";
delete $attr{AutoCommit}; # MySQL still croaks on this one
$dbh = DBI->connect ("DBI:mysql:database=$db", $ENV{LOGNAME}, undef, \%attr) or
croak "connect: $!";
}
$dbh;
} # DBDlogon
> If not, please can we make it so (and if it is, thanks, and when did
> that happen - and I know it was probably 5 years ago, but ...)
>
> >
> >or
> >b) don't want ChopBlanks extended to VARCHAR fields
> >
>
> I take the view that trailing blanks are nominally significant in a
> VARCHAR field. If you want to provide ChopBlanks functionality for
> VARCHAR too, use a separate attribute ChopVarcharBlanks or something.
bitwise?
ChopBlanks => 1, # Chop CHAR fields
ChopBlanks => 2, # Chop VARCHAR fields
ChopBlanks => 4, # Chop TEXT fields (BLOB)
ChopBlanks => 7, # Chop ALL CHAR fields
> I fully accept that distinguishing an empty string from a NULL is hard
> work
And thus should - if possible and not too much backward incompatible - be
supported by DBI/DBD
> - I don't want to explain what Informix does, but it does manage to
> do it for VARCHARs at the storage level. It's just a real pain at the
> client side (meaning for DBD::Informix).
Though we DBD authors have to deal with it on either side, I'd like to take
that hassle away from the programming side (that is the unwary user writing
DBI/DBD scripts)
> >(Let's defer the issue of which _specific_ string types ChopBlanks
> >should apply to for now and just consider CHAR and VARCHAR's at
> >this point.)
>
> OK. NCHAR and CHAR should be chopped. VARCHAR and NVARCHAR should not.
> Anything else is not fully standard. Speaking personally, I don't think
> text blobs should be chopped for the same reasons that varchar should
> not - they are nominally significant.
Depends on the design of the database. The people that chose VARCHAR2 in the
Oracle database I have to work with, did this for storing reasons and
performance, not for significant spaces. To be honoust, at the moment of
design, they were not aware of the fact that empty varchar fields were
converted to NULL in Oracle, I'm sure their decision would have been quite
different if they /would/ have known the trouble they would encounter later on
;)
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
