On Wed, Oct 06, 2004 at 09:43:09AM -0400, Stephen Toney wrote:
> Jeff and Tim,
>
> Sorry, my fault -- the field is a FoxPro Memo field containing a
> single space. As the documentation says, ChopBlanks works only on
> fixed-width char fields.
>
> However, may I suggest that the function be extended to Memo fields?
> That would make the function more symmetrical.
>
> Is there a technical reason for not doing this? Win32::ODBC, which I
> am migrating away from, DOES trim Memo fields automatically.
The DBI tries to follow the basic principle that it should be as
transparent as possible. "Don't mess with the data."
Fixed-width CHAR fields are space-padded by the database.
That's almost always an inconvenience for Perl programs.
The ChopBlanks attribute was designed to make CHAR fields
easier to work with.
The key point is that that the *database* added the spaces
automatically so it's reasonable for the DBI/driver to be able
to remove them automatically.
For other data types, however, if there are space characters
at the end of the string then those space characters *are part of
the data* that was stored. Removing them *is changing the data*.
If you don't want them to be in the data coming out of the database
then they should have been removed on the way in.
Now, having said all that, I can appreciate the convenience of
having a simple way to remove trailing spaces if your data sometimes
has them. I have thought about extending the scope of ChopBlanks
to include other/all string types.
But on balance I don't want to do that. ChopBlanks is too blunt
an instrument for that.
In DBI v2 you'll be able to do things like this for specific columns:
$sth->bind_col(1, undef, { OnFetch => sub { s/\s$// } });
and use something like this to apply to all columns of a certain type:
$dbh->{DefaultBindTypeArgs} = {
SQL_VARCHAR => { OnFetch => sub { s/\s$// } },
};
Tim.
p.s. I think some drivers do apply ChopBlanks to other/all string types.
They'll need changing for DBI v2 or they'll fail the unified test suite.
